By caching the SkImage that is reused across repaints, we allow Skia t
optimize GPU texture caching.
ImmutableBitmap is chosen to own the SkImage because it guarantees that
the underlying pixels cannot be modified. This is not the case for
Gfx::Bitmap, where invalidating the SkImage would be challenging since
it exposes pointers to underlying data through methods like scanline().
This fixes 3/4 of the remaining test failures in wpt/png/apng. Also,
about half of the APNG files on
https://commons.wikimedia.org/wiki/Category:Animated_PNG_files
used to be broken, and they all seem to work properly now :^)
I also refactored the code to be (at least to me) simpler and more
similar to what the spec describes. As a nice side effect, there are now
fewer lines of code than before.
Lastly, I replaced DeprecatedPainter with Painter.
Fixes wpt/png/exif-chunk.html.
At some point there should probably be some mechanism to handle this
outside of the individual decoder plugins. The TIFF decoder seems to
have its own version of this, and as far as I can tell, the JPEG decoder
doesn't handle this at all, even though that's probably the most common
use case for Exif orientations. :^)
Improve handling of APNG chunks by avoiding premature termination when
encountering non-fcTL chunks. With this patch, the browser now passes
additional APNG-related tests in the "png/" Web Platform Tests (WPT)
suite.
Increases code reuse between encoder and decoder a tiny bit.
No behavior change.
(We should use the vectorized version in the future! But first,
we should learn to do the prediction in-place.)
It is unlikely this is needed anymore, and as pointed out things should
now safely return OOM if the bitmap is too large to allocate.
Also, no recently added decoders respected this limit anyway.
Fixes#20872
https://www.haiku-os.org/images/bg-page.png has a size of 0 for
example.
Just ignoring the chunk instead of assuming that the image is sRGB
and has Perceptual rendering intent matches what libpng does
(cf `png_handle_sRGB()`), so let's do that too.
(All other chunk handlers are still strict about size.)
The ideal size is the size the user will display the image. Raster
formats should ignore this parameter, but vector formats can use
it to generate a bitmap of the ideal size.