It appears some websites assume we will not color manage untagged images
and encode metadata in the image's surface data. Chrome matches this
behaviour. We should probably do the same for webcompat.
Differential Revision: https://phabricator.services.mozilla.com/D73737
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- No support for ICC profiles (bug 1634741)
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
Since we don't support downscaling animated images we'll need something like this even we were to try to request a smaller sized decode.
Differential Revision: https://phabricator.services.mozilla.com/D71523
We invalidate for more things than just frames advancing (if we are redecoding and still showing the same frame as before discarding for example). So there is no reason that the dirty rect and a frame being advanced should be linked.
Differential Revision: https://phabricator.services.mozilla.com/D71483
This is actually a one line change. The rest is just removing unneeded parameters.
The composited frame used to be valid for animations that had finished because we saved a separate composited frame, and since the animation had finished it was the final frame, so it had to be valid to display.
Now we don't have a separate composited frame so we only have a valid frame to display if we've decoded up to the current frame. For non-finished animations RequestRefresh will clear mCompositedFrameInvalid, but for finished animations we have to clear it, the easiest place is when we know we are fully decoded.
This problem caused img.decode to never fulfill or reject because we never sent out any frame update notifications because mCompositedFrameInvalid was always false because mAnimationFinished was always true. So we didn't get the invalidation that flipping mCompositedFrameInvalid to false when a full decode finished would cause.
Differential Revision: https://phabricator.services.mozilla.com/D70838
We invalidate for more things than just frames advancing (if we are redecoding and still showing the same frame as before discarding for example). So there is no reason that the dirty rect and a frame being advanced should be linked.
Differential Revision: https://phabricator.services.mozilla.com/D71483
This is actually a one line change. The rest is just removing unneeded parameters.
The composited frame used to be valid for animations that had finished because we saved a separate composited frame, and since the animation had finished it was the final frame, so it had to be valid to display.
Now we don't have a separate composited frame so we only have a valid frame to display if we've decoded up to the current frame. For non-finished animations RequestRefresh will clear mCompositedFrameInvalid, but for finished animations we have to clear it, the easiest place is when we know we are fully decoded.
This problem caused img.decode to never fulfill or reject because we never sent out any frame update notifications because mCompositedFrameInvalid was always false because mAnimationFinished was always true. So we didn't get the invalidation that flipping mCompositedFrameInvalid to false when a full decode finished would cause.
Differential Revision: https://phabricator.services.mozilla.com/D70838
We need this since nsLayoutUtils::SurfaceFromElement expects the
returned frame size to be correct, and we are now wrapping a source
element's image with an OrientedImage.
Differential Revision: https://phabricator.services.mozilla.com/D71243
This makes EXIF orientation metadata honored by default.
Introduce OrientedPixel and UnorientedPixel typed rects and sizes and
use them throughout RasterImage so that we don't confuse which we want.
The reason for doing this rather than having the imgLoader wrap every
RasterImage it creates with an OrientedImage is that returning the
wrapper messes with various notifications, as OrientedImage is not an
ImageResource.
(It would be even better if the JPEG decoder could decode to imgFrames
handling the EXIF orientation itself, but that's a more complicated
change.)
Differential Revision: https://phabricator.services.mozilla.com/D70273
RasterImage will make use of them.
Note that there is one bug fix in this patch, which is that
OrientedImage::OrientSurface now creates a surface of the correct size.
(Previously this code was creating a surface with the underlying
image's size, rather than the correctly oriented size. But we must
not have been calling into that code with our current uses of
OrientedImage.)
Differential Revision: https://phabricator.services.mozilla.com/D70271
This makes EXIF orientation metadata honored by default.
Introduce OrientedPixel and UnorientedPixel typed rects and sizes and
use them throughout RasterImage so that we don't confuse which we want.
The reason for doing this rather than having the imgLoader wrap every
RasterImage it creates with an OrientedImage is that returning the
wrapper messes with various notifications, as OrientedImage is not an
ImageResource.
(It would be even better if the JPEG decoder could decode to imgFrames
handling the EXIF orientation itself, but that's a more complicated
change.)
Differential Revision: https://phabricator.services.mozilla.com/D70273
--HG--
extra : moz-landing-system : lando
RasterImage will make use of them.
Note that there is one bug fix in this patch, which is that
OrientedImage::OrientSurface now creates a surface of the correct size.
(Previously this code was creating a surface with the underlying
image's size, rather than the correctly oriented size. But we must
not have been calling into that code with our current uses of
OrientedImage.)
Differential Revision: https://phabricator.services.mozilla.com/D70271
--HG--
extra : moz-landing-system : lando
This fixes the web-observable bits, but still not the context menu. Patch
incoming for that.
Differential Revision: https://phabricator.services.mozilla.com/D70936
--HG--
extra : moz-landing-system : lando
Currently, `NotificationObserverWrapper` would leak because no one delete it. When clearing the weak pointer in `ImageDecoderListener`, that won't destroy `NotificationObserverWrapper` itself, but only destroy the `WeakReference<NotificationObserverWrapper>`.
Therefore, we should remove `NotificationObserverWrapper` and use a strong reference to hold `imgINotificationObserver` directly.
Differential Revision: https://phabricator.services.mozilla.com/D70569
--HG--
extra : moz-landing-system : lando
We use FRAME_UPDATE and FRAME_COMPLETE notifications to check if we should resolve/reject img.decode promises. But all of the FRAME_UPDATE/FRAME_COMPLETE notifications for image/test/crashtests/1443232-1.gif come before we change the surface cache entry from a placeholder to available. So RequestDecodeForSize returns false and we don't resolve and we don't get anymore notifications.
In this case the DECODE_COMPLETE notifications comes after we mark the surface cache entry as available so checking if we should resolve for DECODE_COMPLETEs would also work, but it seems reasonable for consumers to expect that they can get a frame after getting a FRAME_COMPLETE notification for it.
Differential Revision: https://phabricator.services.mozilla.com/D70312
--HG--
extra : moz-landing-system : lando
Andrew Osmond
Nathan Froyd
Mihai Alexandru Michis
Jon Bauman
Razvan Maries
Bogdan Tara
Sylvestre Ledru
Timothy Nikkel
Simon Giesecke
Olivier Tilloy
Narcis Beleuzu
Andreea Pavel
Christoph Kerschbaumer
Daniel Varga
Cameron McCormack
Csoregi Natalia
Emilio Cobos Álvarez
alwu
Edgar Chen
Noemi Erli