Shareable Vulkan image allocation on Linux relies on the dma-buf
interface, which is a Linux-specific thing. Therefore, we should only be
compiling it (and any code that uses it) on Linux. This change adds
preprocessor guards to do that. Enabling similar functionality on other
operating systems will need to leverage analogous interfaces on those
platforms, e.g. win32 handles on Windows.
All Vulkan image code will now be guarded by the USE_VULKAN_IMAGES
preprocessor definition, currently enabled on Linux if Vulkan is
available. Additionally, we shuffle around some code in
OpenGLContext.cpp to simplify the preprocessor conditionals.
This adds a new PaintingSurface creation function, create_from_vkimage,
which returns a PaintingSurface backed by a vulkan image. It's analogous
to the existing create_from_iosurface function. In both cases the
backing object will be imported into Skia as a render target and then an
SkSurface will be wrapped around that.
In order to ensure that the image will not be freed while still in use
by Skia, we will manually bump the refcount of the VulkanImage object
before passing it to Skia and then use the releaseCallback parameter of
WrapBackendRenderTarget to register a callback that drops this
reference.
Now, when Skia backend context is available by the time backing stores
are allocated, there is no need to have a separate BackingStore class.
This allows us to get rid of BackingStore -> PaintingSurface cache.
This is implemented by these related changes:
* The Skia alpha type 'Opaque' is selected for surfaces that were
created with the intention of not having an alpha channel.
Previously we were simply creating one with alpha.
* Clearing now happens through Skia's `clear()` which always uses the
source color's value for the result, instead of setting all values
to 0.
* CanvasRenderingContext2D selects a different clearing color based on
the `alpha` context attribute's value.
With this change we ensure that Skia surfaces are allowed to be created
or destroyed only by one thread at a time. Not enforcing this before
resulted in "Single owner failure." assertion crashes in debug mode on
pages with canvas elements.
The Skia Ganesh backend we currently use doesn't support painting from
multiple threads, which could happen before this change when the main
thread used Skia to paint on the HTML canvas while the rendering thread
was working on display list rasterization.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/4172
By doing that we eliminate the need for the vertical flip flag.
As a side effect it fixes the bug when doing:
`canvasContext2d.drawImage(canvasWithWebGLContext, 0, 0);`
produced a flipped image because we didn't account for different origin
while serializing PaintingSurface into Gfx::Bitmap.
Visual progress on https://ciechanow.ski/curves-and-surfaces/
If not set, when copying pixels into the SkImage, skia assumes that the
color space is the same as the input, so no transformation is done. We
are currently setting the color space to sRGB, this is fine for now as
it allows us to start making some transformations, but down the road we
will want to set that to the actual output's display color space.
It makes it a little bit easier to distinguish which one of
read_into_bitmap and write_from_bitmap actually modify the Bitmap that
was passed to the method. NFC.
Previously, constructing a PaintingSurface from an IOSurface required
wrapping IOSurface into a Metal texture before passing it to the
PaintingSurface constructor. This process was cumbersome, as the caller
needed access to a MetalContext to perform the wrapping.
With this change SkiaBackendContext maintains a reference to the
MetalContext which makes it possible to do:
IOSurface -> MetalTexture -> SkSurface within a PaintingSurface
constructor.
