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.
The added precision of doubles is most likely not needed here and floats
are usually cheaper than doubles, so lets always stick to them.
This also simplifies some calls to sin+cos to AK:sincos and a call to
atan(1/x) to atan2(1,x) to avoid a division.
It's a common pattern on the web to draw a circle/ellipse by setting
the border-radius to 50%. Previously the painter would do a lot of
extra work painting and clipping each corner, this now detects that
case and replaces it with a single call to fill_ellipse().
The issue mentioned in the previous FIXME also applied to circles,
I just had not noticed. This is still not a prefect fix rather it
just papers over it, but it now seems to render circles correctly.
This is a first pass at antialiased outline ellipses, currently
this is done by painting two filled AA ellipses, and then
subtracting the inner ellipse from the outer.
This produces a good result, but unfortunately requires allocating
a temporary bitmap in the painter. I did try a simpler method
using the existing line painting functions, and drawing the
ellipse as many line segments, but that produced very poor results.
I think with some work it should be possible to remove the extra
allocation, and I've left a big FIXME for this, but I could not
get this working well.
This function returns an Optional<Color> and is given an
alpha_threshold. If all pixels above that alpha threshold are the
same color, it returns the color, otherwise it returns an empty
optional.
.jpg){kind=link}