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.
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
The display list is an immutable data structure, so once it's created,
rasterization can be moved to a separate thread. This allows more room
for performing other tasks between processing HTML rendering tasks.
This change makes PaintingSurface, ImmutableBitmap, and GlyphRun atomic
ref-counted, as they are shared between the main and rendering threads
by being included in the display list.
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/
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.
OpenGL's origin is at the bottom-left corner, while Skia's origin is at
the top-left corner. This change adds a transformation to compensate for
this difference when rendering PaintingSurface attached to WebGL
context.
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.
