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. :^)
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
Error::from_string_literal now takes direct char const*s, while
Error::from_string_view does what Error::from_string_literal used to do:
taking StringViews. This change will remove the need to insert `sv`
after error strings when returning string literal errors once
StringView(char const*) is removed.
No functional changes.
This commit moves the length calculations out to be directly on the
StringView users. This is an important step towards the goal of removing
StringView(char const*), as it moves the responsibility of calculating
the size of the string to the user of the StringView (which will prevent
naive uses causing OOB access).
Is it another great upgrade to our PNG encoder like in 9aafaec259?
Well, not really - it's not a 2x or 55x improvement like you saw there,
but still it saves something:
- a screenshot of a blank Serenity desktop dropped from about 45 KiB
to 40 KiB.
- re-encoding NASA photo of the Earth to PNG again saves about 25%
(16.5 MiB -> 12.3 MiB), compared to not using filters.
[1]: https://commons.wikimedia.org/wiki/File:The_Blue_Marble_(remastered).jpg
Previously we were hand-writing all the Zlib and raw Deflated data
structures here, but now PNGs will be compressed using ZlibCompressor
which will actually try to compress something! :^)
Note that we don't do any filtering that should help compress data even
more, but even now the results are pretty good:
- screenshots of my Serenity desktop are take now about 55 KiB, where
previously it was 3 MiB.
- re-encoding NASA photo of the Earth[1] to PNG shows a 2x improvement
(34.3 MiB -> 16.5 MiB).
[1]: https://commons.wikimedia.org/wiki/File:The_Blue_Marble_(remastered).jpg
This now allows passing a 'fill_color' to the blur, any fully
transparent pixels will be replaced with this color (with the alpha
set to 0).
For box-shadows, if this color is set to the same as the shadow,
the issues around the fringes are fixed. This also fixes some places
where dark shadows appeared light / the wrong color.
This adds an implementation of StackBlur which is a very efficient
blur that closely approximates a gaussian blur. It has a number of
benefits over the existing FastBoxBlurFilter:
1. It's faster (~half the pixel lookups of a single box blur pass)
2. It only requires a single pass over image to produce good results
- (Rather than the 3 the box blur requires)
3. It only needs to allocate a buffer of `blur_radius * 2 + 1` colors
- These easily fits on the stack for any reasonable radius
For a detailed explanation of the algorithm check out this link:
https://observablehq.com/@jobleonard/mario-klingemans-stackblur
Change from 4 vectors of u8 to a single vector of a struct of 4
u8. Since all the accesses are on the same indicies into each vector
the cache pressure is decreased by co-locating the data.
When scrolling up and down in the `box-shadow` example page the
profile changes from about 75% of the function calls being in
`apply_single_pass()` to only about 70% on my machine.
This is a reimplementation of draw_triangle that manages without
floating point arithmetic.
It's most important property, compared to the previous implementation is
that rotating the same triangle 90 degrees won't drastically change the
appearance of that triangle. (it did before)
This adds simple dotted lines (horizontal/vertical only for now).
There's a little number fudging added in to make sure the final
dot is always drawn at the endpoint (for lines with at least a
handful of dots).
If you wanted to upscale an image, you had two options:
- use Nearest Neighbor: it's probably a good choice. The image stays
sharp.. unless you aren't using integer scales.
- use Bilinear blending, but this on the other hand, doesn't handle
upscaling well. It just blurs everything.
But what if we could take the best of both of them and make the image
sharp on integers and just blur it a little when needed?
Well, there's Smooth Pixels!
This mode is similar to the Bilinear Blend, with the main difference
is that the blend ratio is multiplied by the current scale, so the blur
on corners can be only 1px wide.
From my testing this mode doesn't handles downscaling as good as the
Bilinear blending though.
.jpg){kind=link}