On Tuesday, 17 April 2018 07:35:44 PDT Konstantin Tokarev wrote:
> FWIW, hardware decoding of JPEG is usually supported by devices featuring
> hardware video decoding support.
But that's still decompressing it. You're just using the HW to do it faster.
The only use-case I can easily think of for
Alex Blasche (maanantai 16. huhtikuuta 2018 16.47)
>>> ... I do like to emphasize though that the dates for first beta and
>>> first RC are important (and FF is alpha) because they define times
>>> when certain level of changes are no longer permitted (e.g. after
>>> first beta no API changes). The
17.04.2018, 17:33, "Иван Комиссаров" :
> At the point i wrote the plugin, my usecase was simple - to convert plain
> QImages to and from DDS icons (used in starcraft2, which uses quite a few
> formats DDS can handle).
> But yes, i forgot floating point textures.
> Compressed textures (DXTN/ATI2
At the point i wrote the plugin, my usecase was simple - to convert plain
QImages to and from DDS icons (used in starcraft2, which uses quite a few
formats DDS can handle).
But yes, i forgot floating point textures.
Compressed textures (DXTN/ATI2) are just compressed (a)rgb32, nobody uses
compresse
> From: "Giuseppe D'Angelo"
> On 17/04/18 13:21, Иван Комиссаров wrote:
> > Ok, there's another problem with QImage - ARGB64 and friends... This can
> > be solved adding QImage::pixel64() or something like that... or use
> > QTexture with 64bit "pixel"
>
> And a bunch of packed formats not curr
On 17/04/18 13:21, Иван Комиссаров wrote:
Ok, there's another problem with QImage - ARGB64 and friends... This can
be solved adding QImage::pixel64() or something like that... or use
QTexture with 64bit "pixel"
And a bunch of packed formats not currently supported, and floating
point channels
Ok, there's another problem with QImage - ARGB64 and friends... This can be
solved adding QImage::pixel64() or something like that... or use QTexture
with 64bit "pixel"
2018-04-17 11:48 GMT+03:00 Иван Комиссаров :
>
>
> 2018-04-17 11:02 GMT+03:00 Giuseppe D'Angelo :
>
>> On 17/04/18 08:09, Иван К
On 17.04.2018 12:08, Edward Welbourne wrote:
Alex Blasche (maanantai 16. huhtikuuta 2018 16.47)
... I do like to emphasize though that the dates for first beta and
first RC are important (and FF is alpha) because they define times
when certain level of changes are no longer permitted (e.g. aft
> -Original Message-
> From: Edward Welbourne
> Sent: tiistai 17. huhtikuuta 2018 12.09
> To: Jani Heikkinen ; Alex Blasche
>
> Cc: Qt development mailing list
> Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for release
> process change
>
> To paraphrase and possibly ma
Alex Blasche (maanantai 16. huhtikuuta 2018 16.47)
>>... I do like to emphasize though that the dates for first beta and
>>first RC are important (and FF is alpha) because they define times
>>when certain level of changes are no longer permitted (e.g. after
>>first beta no API changes). Therefore,
2018-04-17 11:02 GMT+03:00 Giuseppe D'Angelo :
> On 17/04/18 08:09, Иван Комиссаров wrote:
>
>> Looking at the email archives: it was fuzzed through AFL. I don't have
>>> the test images still around, but in my experience a simple multi-image
>>> file was enough to trigger a crash. (I used to see
On 17/04/18 08:09, Иван Комиссаров wrote:
Looking at the email archives: it was fuzzed through AFL. I don't have the test
images still around, but in my experience a simple multi-image file was enough
to trigger a crash. (I used to see this in Creator, when accidentally opening a
DDS in its bu
> -Original Message-
> From: Jani Heikkinen
> I have to disagree a bit: Alpha and beta phases are important and schedule
> for FF
> (and Alpha) as well. But for beta and RC we really don't need it: After API
> review
> is done we will enter in beta phase (and at this same time beta1 is
13 matches
Mail list logo
