I forgot that we run the tests twice in this file, once with the downscale pref on and once with it off. Restore the second time for the moz-icon tests. And adjust the fuzz because it can be lower now.
Differential Revision: https://phabricator.services.mozilla.com/D36415
--HG--
extra : moz-landing-system : lando
Changes:
- migrate over `mochitest-plain` to macosx1014
- disable some tests that are known to be problematic on macosx1014; they are noted in the comments
Differential Revision: https://phabricator.services.mozilla.com/D34589
--HG--
extra : moz-landing-system : lando
Creating QCMS profiles and transforms are fairly expensive operations
and not necessary for metadata decoding. We can reduce the time required
for PNG metadata decoding by skipping this. The JPEG and WebP decoders
already do this.
Differential Revision: https://phabricator.services.mozilla.com/D35500
This adds variants of 1000x1000 green pixels encoded for each image
format. This includes different pixel representations (e.g. CMYK, YCbCr,
grayscale, lossy, lossless) as well as opaque and partially transparent.
JPG, PNG and WebP include either an RGB or gray ICC profile to test
color management integration as well.
Differential Revision: https://phabricator.services.mozilla.com/D34502
It will cause releasing nsLoadGroup which doesn't like being released off main thread.
Differential Revision: https://phabricator.services.mozilla.com/D33590
--HG--
extra : moz-landing-system : lando
GIF images should not apply CMS transforms if disabled by caller via
SurfaceFlags::NO_COLORSPACE_CONVERSION. WebP images should reject any
non-RGB ICC profiles, not just grayscale profiles.
Differential Revision: https://phabricator.services.mozilla.com/D26372
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
With WebRender, we had observed that the print preview for animated
images was not displaying correctly. It should display the first frame
but it was showing nothing the first time the preview was opened. Once
the decoded image was available in the cache, it would display
correctly if the preview was reloaded.
The StartDecoding and RequestDecode variants always requested
FRAME_CURRENT for animated images. They should use FRAME_FIRST for
static requests / FrozenImage. Correcting this fixes the print preview.
Differential Revision: https://phabricator.services.mozilla.com/D32033
Looks like this is left over from a partial attempt at making GetStockIcon async like GetHIconFromFile.
But I don't think it needs to be async, the only system call SHGetStockIconInfo doesn't have anything about background thread like SHGetFileInfo.
Differential Revision: https://phabricator.services.mozilla.com/D31013
As stated in other patches in this bug, the system call has to happen off main thread, and it has to always be on the same thread. So we dispatch the task to that thread and synchronously wait on the main thread for it to finish.
Differential Revision: https://phabricator.services.mozilla.com/D29626
Windows doesn't like more than one thread (at the same time?) calling SHGetFileInfoW. So we use the same thread to avoid this.
We also need to call CoInitialize on the thread we do this.
Differential Revision: https://phabricator.services.mozilla.com/D28423
We need to call CoInitialize, so we need to include the objbase.h header. That defines some generic boolean stuff, which conflicts with something that libjpeg defines. I tried working around it, but I gave up, this solution seems fine.
Differential Revision: https://phabricator.services.mozilla.com/D28422
This mutex only protects the iothread, not the rest of the decodepool. There is a different monitor for that in DecodePoolImpl.
Differential Revision: https://phabricator.services.mozilla.com/D28420
