Also, add `clang-format off` directives to files which are ignored by
.clang-format-ignore so that the editor isn't trying to reformat them
Differential Revision: https://phabricator.services.mozilla.com/D76217
Since AnimationState::UpdateState now depends on a specific frame of the animation being in the surface cache we need to call UpdateState whenever we add a new frame.
Depends on D73583
Differential Revision: https://phabricator.services.mozilla.com/D73584
It takes a frame count argument but probably never gets a value we haven't already seen in a NotifyProgress call, so this doesn't fix anything as far as I know.
Depends on D73564
Differential Revision: https://phabricator.services.mozilla.com/D73583
The img.decode promise for animated images that aren't in the document might not resolve in common cases. Specifically for animated images that have been decoded and then discarded, so that mCompositedFrameInvalid is true.
mCompositedFrameInvalid is cleared by either:
1) the image is fully decoded and NotifyDecodeComplete is called.
2) RequestRefresh is able to advance to the current frame.
We don't call RequestRefresh on animated images that aren't in the document and we only decode a certain number of frames ahead of the current frame (even for fully retained animation buffers), so neither of these will happen with long enough animated images.
So we need to make sure that mCompositedFrameInvalid eventually gets cleared any time a decode is requested (which the FrameAnimator gets notified about via GetCompositedFrame). We do that be calling UpdateState in GetCompositedFrame whenever mCompositedFrameInvalid is true and the image is in the surface cache.
This runs into a second problem: UpdateState uses |mIsCurrentlyDecoded = aResult.Surface().IsFullyDecoded()| to determine when to clear mCompositedFrameInvalid. As mentioned above, we don't fully decode animated images. Further, for animated images that are large enough we use a discarding animation buffer that never keeps around all the frames and so IsFullyDecoded always returns false. So we replace that with a check that we can seek to the current animated frame index.
Differential Revision: https://phabricator.services.mozilla.com/D73564
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
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
Jon Bauman
Mihai Alexandru Michis
Masatoshi Kimura
Dorel Luca
wesj
Andrea Marchesini
Narcis Beleuzu
Coroiu Cristina
Kershaw Chang
Cameron McCormack
Christian Holler (:decoder)
Honza Bambas
Edgar Chen
Sylvestre Ledru
Matt Woodrow
Timothy Nikkel
Simon Giesecke
Ian Moody
Andrew Osmond
Nathan Froyd
Razvan Maries
Bogdan Tara
Olivier Tilloy
Andreea Pavel
Christoph Kerschbaumer
Daniel Varga