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.
This commit adds draw_ellipse() and moves the shared code
for circles and ellipses to draw_ellipse_part().
draw_ellipse_part() can draw an entire circle in one call using
8-way symmetry and an ellipse in two calls using 4-way symmetry.
We were always calling llround[fd], even for floating point targets.
Also for rounding to integer, we don't need to have C99's rounding rules
and can just cast, assuming the standard rounding mode.
Clang didn't accept the friend declaration here, as the class has a
requires clause attached to it, and I couldn't immediately figure
out what it wants instead.
Add accessors for VectorN::m_data and use those where needed instead
for now.
.jpg){kind=link}