Currently the default is false, but this is not the best strategy
for most filters producing artifacts on the borders, and wrap-around
option ends up being better, producing less artifacts.
Doesn't use them in libc headers so that those don't have to pull in
AK/Platform.h.
AK_COMPILER_GCC is set _only_ for gcc, not for clang too. (__GNUC__ is
defined in clang builds as well.) Using AK_COMPILER_GCC simplifies
things some.
AK_COMPILER_CLANG isn't as much of a win, other than that it's
consistent with AK_COMPILER_GCC.
This fixes an issue where, when looping over the components of a
composite glyph, we used to mutate the affine transformation of the
glyph itself when computing the transformations of its components.
(AffineTransform::multiply() is non-const).
This remained undetected for a long time as HeaderCheck is disabled by
default. This commit makes the following file compile again:
// file: compile_me.cpp
#include <LibDNS/Question.h>
// That's it, this was enough to cause a compilation error.
Likewise for most other files touched by this commit.
This fixes a bug in ladybird where it was crashing while rendering
characters like ščćž in the Noto Sans Regular font.
That font renders those characters as a composite where the caret
has numberOfContours = -1. When using the rasterize_impl simple path
for that, it would negatively overflow the offsets.
This will be needed so we can apply filter effects to the backdrop
of an element in LibWeb.
This now also allows getting a crop of a bitmap in a different format
than the source bitmap. This is for if the painter's bitmap does not
have an alpha channel, but you want to ensure the cropped bitmap does.
This amount can be handled in the filter's implementation or if
not it will default to mixing between the new and previous pixel.
This behaviour is used for implementing CSS filters that allow stuff
like grayscale(70%).
Instead of just keeping them in an unsorted Vector, which led to
increasingly noticeable O(n) lookups, we now cache a list of Typefaces
per family name.
In some artificial full screen blitting profiling, I've seen `memcpy`
take up about 4% fewer samples each time I measure. It seems like
`fast_u32_copy` is not as fast as it'd like to believe.
Also make the font discovery algorithm search subdirectories as well.
This will be used by Ladybird to discover more fonts on non-Serenity
systems. :^)
Our bilinear scaling logic worked well for upscaling, but during
downscaling the bitmap was often shifted one pixel to the bottom right.
This is a common problem, described here in more detail:
https://bartwronski.com/2021/02/15/bilinear-down-upsampling-pixel-grids-and-that-half-pixel-offset/
Fix it by calculating coordinate shift values that align the pixel's
boundaries between the source and target pixels before selecting the
source pixels to interpolate.
with the RenderAbove WindowMode. This mode will ensure child
windows always draw above their parents, even when focus is lost.
RenderAbove modals are automatically themed the same as the old
ToolWindows. Fixes ToolWindows rendering above ALL normal windows,
regardless of parent. We can't rely on WindowType to create these
sort of effects because of WindowManager's strict display hierarchy.
Superceded by to_floating_cursor_position() as a more accurate way
to reposition windows on untile. Effectively made set_size_around()
dead code, so the remnants can be removed.
This allows us to treat unqualified, minimally-qualified, and
fully-qualified emojis the same as long as emoji filenames are in their
least qualified form (with respect to emoji presentation).
For example, the transgender flag emoji has 4 possible forms:
1F3F3 FE0F 200D 26A7 FE0F ; fully-qualified # 🏳️⚧️
1F3F3 200D 26A7 FE0F ; unqualified # 🏳⚧️
1F3F3 FE0F 200D 26A7 ; unqualified # 🏳️⚧
1F3F3 200D 26A7 ; unqualified # 🏳⚧
In order to treat them all as the same, we now drop all forms down
to 1F3F3 200D 26A7 (skipping any FE0F codepoints) and then do the
lookup for that form.
The order of PNG compression is raw pixel data -> filter -> compress.
For decompression, the order is reversed, so that means uncompress ->
unfilter -> raw pixel data. Previously, the PNG decoder was converting
to raw pixel data before unfiltering, which was a problem when using
indexed color palettes, since each pixel's palette index could change
during unfiltering (e.g. it was unfiltering after already choosing
the color from the palette index). This was leading to 'Palette index
out of range' errors on files that both:
- Had scanlines with some sort of filtering
- Didn't use the full range of possible palette indices for their bit
depth.
Also, because filtering now happens before converting to pixel data,
filtering acts on bytes instead of pixels, meaning that the
implementation of each filter type now maps much more directly to
the specification:
http://www.libpng.org/pub/png/spec/1.2/PNG-Filters.html
We can't rely on the caller to keep the code points alive, and this
was sometimes causing incorrect cache hits, leading to the wrong
emoji being displayed.
Fixes#14693
While for a general purpose encoder a good balance between compression
speed and size by default is important, in case of PNG it don't matter
that much, as it was said in #14594.
Also note that it's not the best we can have. We use zlib's compression
level, which has a range of 0-4, while our deflate implementation ranges
from 0 to 5.
Remove the static PNG bitmaps we've been using for GUI radio buttons
and replace them with on-the-fly pixel painting.
This fixes a long-standing issue where radio buttons always looked the
same, regardless of system theme settings. :^)
