Our Color::to_premultiplied() and Color::to_unpremultiplied() used
integer truncation.
Apple’s Accelerate framework (and many other libraries) use
round-to-nearest, which avoids bias and produces results that differ
by ±1 in many cases.
This commit switches both helpers to round-to-nearest and clamps the
results to [0,255]. For alpha==0 we now return fully transparent black
(0,0,0,0) to align with common conventions, instead of preserving RGB.
We currently have a mixup in LibWeb between code unit offset and glyph
offset during hit testing. These extra fields will allow us to correct
this discrepency.
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.
This introduces the ability to allocate Vulkan images which can be
shared across graphics APIs or across processes using the Linux dma-buf
interface.
The create_shareable_vulkan_image function takes a VulkanContext, image
width, height, and format, and an array of DRM format modifiers
representing image memory layouts accepted by the caller. The function
will intersect this list with the list of modifiers supported by the
Vulkan implementation, ensuring the resulting image uses one of those
layouts (exactly which one is up to the implementation). The function
will return a VulkanImage object, which is reference-counted and
encapsulates the VkImage itself as well as the backing memory
allocation. It also stores various image parameters such as usage,
tiling, etc.
The VulkanImage::get_dma_buf_fd function will create a file descriptor
representing the image's backing dma-buf which can then be imported by a
different API or sent over a unix domain socket.
The current Color::interpolate_color method does not follow the specs
properly. Started improving it by handling premultiplied alpha in color
interpolation.
Only one WPT test covers this (color-transition-premultiplied), which we
currently pass due to a different approach in Color.mixed_with.
When converting rotate transform functions `sin` and `cos` can sometimes
be inaccurate. To avoid these inaccuracies we:
- Mod the angle to minimise inaccuracies in the first place.
- Discard tiny (smaller than epsilon) values returned by `sin` and
`cos` as inaccuracies.
This is in line with other browsers (e.g. Gecko and WebKit).
Previously we would omit the letter spacing for the end glyph of each
chunk in a misguided attempt to conform to the spec's instruction that
we "really should not append letter spacing to the right or trailing
edge of a line", this behaviour can be removed entirely as other
browsers (Firefox, Chrome) don't implement it either.
`aa_translation` is something we inherited from times when
AntiAliasingPainter was a thing. This change replaces it by applying
offset directly to path.
Coverity static analysis reports that the code that scans the queue
families for one that has the graphics bit, can be -1 if none are
found, which could cause a problem when the -1 (signed) value is
used later as an index in a uint32_t (unsigned) variable.
Its not immediately clear how often this could occur, not finding
a queue family with the graphics bit, but adding some protecting
just in case.
This produces more granural information on the actual pixel errors
present between two bitmaps. It now also asserts that both bitmaps are
the same size, since we should never compare two differently sized
bitmaps anyway.
By keeping track of the enclosing range around all Unicode ranges of a
FontCascadeList entry, we can quickly reject any code point that's
outside all ranges.
This knocks font_for_code_point() from 7% to 3% in the profile when
scrolling on https://screenshotone.com/
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.
Our floating point number parser was based on the fast_float library:
https://github.com/fastfloat/fast_float
However, our implementation only supports 8-bit characters. To support
UTF-16, we will need to be able to convert char16_t-based strings to
numbers as well. This works out-of-the-box with fast_float.
We can also use fast_float for integer parsing.
Gfx::Bitmap only supports a bit depth of 8, therefore we refused to
load AVIF images which didn't have this bit depth.
However, we can tell the libavif decoder to reduce the output depth by
setting avifRGBImage.depth to 8. This allows us to support any input
depth.
Makes images load on https://www.ikea.com/ which uses Cloudflare Images
to re-encode their images to 16-bit AVIF.
