Using the Rust yuv crate, eagerly convert from YUV to RGBA on the CPU
when a GPU context is unavailable.
Time spent converting an 8-bit YUV frame with this crate is better than
libyuv on ARM by about 20%, and on x86 with AVX2, it achieves similar
numbers to libyuv.
Storing these was pointless, since they're only used briefly to provide
the info needed to upload the buffers to the GPU.
For BT.2020 coefficients, we can just say that the bit depth is 16 bits
since we're always bit replicating to that for Skia's shaders.
When an ImmutableBitmap is constructed from video data, there's a
probability that we're dealing with YUV data and we do not yet have an
sk_image to work with.
No regression test since we require a GPU to end up in this situation.
Fixes the background scenery on https://screen.toys/roadtrip/.
If we have a Skia backend context available, use it to make image
snapshots. Drops blitting CPU usage from 55% to 0.6% for slither.io on
my machine.
Adds a fallback to ::bitmap() to store a bitmap blitted from an SkImage
if that's available.
Previously, bitmap-backed images were stored as raster SkImages and
re-uploaded to the GPU every frame. This caused significant overhead
in createProxyFromBitmap, uploadToTexture, and memmove.
Now, ensure_sk_image() converts raster SkImages to GPU textures using
SkImages::TextureFromImage() on first use. The texture is cached and
reused for subsequent frames.
- Mipmaps disabled (kNo) to reduce upload time and memory
- Budgeted (kYes) to let Skia manage GPU memory and evict under pressure
- Falls back to raster rendering if no GPU context available
This saves us from having our own color conversion code, which was
taking up a fair amount of time in VideoDataProvider. With this change,
we should be able to play high resolution videos without interruptions
on machines where the CPU can keep up with decoding.
In order to make this change, ImmutableBitmap is now able to be
constructed with YUV data instead of an RBG bitmap. It holds onto a
YUVData instance that stores the buffers of image data, since Skia
itself doesn't take ownership of them.
In order to support greater than 8 bits of color depth, we normalize
the 10- or 12-bit color values into a 16-bit range.
The verified pixel output in this test just reflects currently observed
behavior, I have not verified that all cases output the correct data wrt
what the spec expects.
This makes it so that we can visit satellite and hybrid view on
maps.apple.com. Previously this would crash from a bounds check due to
us asking Skia to write 32bpp RGBx8888 data into a buffer sized for
24bpp RGB888.
This factors the conversion logic to be independent from WebGL code,
allowing us to write unit tests for it that can run in CI (since WebGL
can't run in CI).
We don't discern between opaque and non-opaque alpha types in LibGfx,
which at some point we might need to do. But for now, assume all opaque
Skia surfaces have premultiplied alpha.
Fixes#6892.
When decoding data into bitmaps, we end up with different alpha types
(premultiplied vs. unpremultiplied color data). Unfortunately, Skia only
seems to handle premultiplied color data well when scaling bitmaps with
an alpha channel. This might be due to Skia historically only supporting
premultiplied color blending, with unpremultiplied support having been
added more recently.
When using Skia to blend bitmaps, we need the color data to be
premultiplied. ImmutableBitmap gains a new method to enforce the alpha
type to be used, which is now used by SharedResourceRequest and
CanvasRenderingContext2D to enforce the right alpha type.
Our LibWeb tests actually had a couple of screenshot tests that exposed
the graphical glitches caused by Skia; see the big smiley faces in the
CSS backgrounds tests for example. The failing tests are now updated to
accommodate the new behavior.
Chromium and Firefox both seem to apply the same behavior; e.g. they
actively decode PNGs (which are unpremultiplied in nature) to a
premultiplied bitmap.
Fixes#3691.
This patch introduces the `Gfx::ColorSpace` class, this is basically a
serializable wrapper for skia's SkColorSpace. Creation of the instances
of this class (and thus ICC profiles parsing) is performed in the
ImageDecoder process. Then the object is serialized and sent through
IPC, to finally be handed to skia for rendering.
However, to make sure that we're not making all LibGfx's users dependent
on Skia as well, we need to ensure the `Gfx::ColorSpace` object has no
dependency on objects from Skia. To that end, the only member of the
`ColorSpace` class is the opaque `ColorSpaceImpl` struct. Though, there
is on issue with that design, the code in `DisplayListPlayer.cpp` needs
access to the underlying `sk_sp<SkColorSpace>`. It is provided by a
template function, that is only specialized for this type.
Doing this work allows us to pass the following WPT tests:
- https://wpt.live/css/css-color/tagged-images-001.html
- https://wpt.live/css/css-color/tagged-images-003.html
- https://wpt.live/css/css-color/tagged-images-004.html
- https://wpt.live/css/css-color/untagged-images-001.html
Other test cases can also be found here:
- https://github.com/svgeesus/PNG-ICC-tests
Note that SkColorSpace support quite a limited amount of color spaces,
so color profiles like the ones in [1] or the v4 profiles in [2] are not
supported yet. In fact, SkColorSpace only accepts skcms_ICCProfile with
a linear conversion to XYZ D50.
[1] https://www.color.org/browsertest.xalter
[2] https://www.color.org/version4html.xalter
