In testing a particular website (https://www.icpms.com), WebContent
was crashing with infinite recursion in draw_circle_arc_intersecting.
Presumably, radius must be > 0 to paint something, so this trivial
patch simply returns if radius <= 0. The website in question no longer
crashes WebContent.
This matches the rename of RGBA32 to ARGB32. It also makes more sense
when you see it used with 32-bit hexadecimal literals:
Before:
Color::from_rgba(0xaarrggbb)
After:
Color::from_argb(0xaarrggbb)
The ARGB32 typedef is used for 32-bit #AARRGGBB quadruplets. As such,
the name RGBA32 was misleading, so let's call it ARGB32 instead.
Since endianness is a thing, let's not encode any assumptions about byte
order in the name of this type. ARGB32 is basically a "machine word"
of color.
This necessitates switching from passing a single code point to the
callback to passing a non-const Utf8CodePointIterator instead.
Note that the text selection mechanisms in LibGUI and LibWeb don't
handle this properly yet; they still assume that each code point
renders as one glyph. Similarly, width calculations for text widths
don't either, so a single such an emoji will require space for more
than one glyph.
It also doesn't work in LibVT's TerminalWidget, where each code point
is handled and rendered separately, so LibGfx never gets a chance to
check if subsequent code points could result in a combined emoji.
This method is commonly used by bitmap text rendering. Adding support
for color blending enables support in the browser for text opacity using
their color property.
This patch adds support for drawing triangular waves.
For now those can only be horizontal, but as they are intended for
underlining text, it's an okay way to handle this.
Lines are drawn using squares the size of the thickness, so if the
length of the line was not a multiple of the thickness, the end of the
line was not drawn correctly.
The algorithm is quite simple: You grab a 2x2 area of pixels around the
point you want from the source bitmap, and then linearly interpolate
between them based on how far they are from that point.
This works well when scaling up images, and moderately well when scaling
down - small details may get skipped over. The way GPUs solve this is
with mipmaps, which is not something I want to get into right now. (And
increases the memory usage per bitmap by 50%.)
I have not focused on performance, but this does reuse much of the
existing fixed-point calculation, and uses constexpr so that the
performance for nearest-neighbor should be the same as it was
previously.
Note: most systems now use a font's .notdef character for unknown
glyphs (commonly the tofu box) and reserve 0xFFFD for encoding
errors. Until Serenity supports tofu, 0xFFFD is a preferable, if
deprecated, alternative to '?' to reduce ambiguity.
In some cases, we were infinite-looping when asked to paint something
with a thickness of '0', so now every Painter method that takes a
thickness, does a check for a thickness <= 0 and bails early. After all,
you can't draw something that's 0px wide. :^)
To avoid expensive floating point operations the values are put in the
upper half of an integer which is then used for calculations.
When the src_rect is sufficiently large (when, say, PixelPaint is zoomed
in x100), the precision provided by this strategy with regular
32-bit-long ints is no longer enough.
This patch changes the used types to i64, which are 64 bits wide and the
shifting is increased to 32 bits.
On the 32-bit-arch a i64 doesn't fit in a single register anymore but
it's probably okay to trust the compiler to do clever stuff around this
issue.
Without this, the bounding rect for the text as generated by TextLayout
can go beyond the bounds of the user-supplied drawing rect and cause the
text to overlap because of the line_rect.intersect(rect) a few lines
below.
We were accidentally calling TextDirection::get_text_direction with a
String instead of a UtfView, which meant each byte was treated as a
codepoint, resulting in incorrect identification of text direction.
Previously there was no way to draw rectangles with any specific
thickness, like we can do with ellises, for instance. This method
is just a simple wrapper around `draw_line()` several times. At
least for now, we don't need to do anything sophisticated since
this will only be used by PixelPaint.`
This class now contains all the fun bits about laying out text in a
rect. It will handle line wrapping at a certain width, cutting off lines
that don't fit the given rect, and handling text elision.
Painter::draw_text now internally uses this.
Future work here would be not laying out text twice (once actually
preparing the lines to be rendered and once to get the bounding box),
and possibly adding left elision if necessary.
Additionally, this commit makes the Utf32View versions of
Painter::draw_text convert to Utf8View internally. The intention is to
completely remove those versions, but they're kept at the moment to keep
the scope of this PR small.
Before this patch, some glyphs had a weird off-by-1 vertical position
which looked really jarring at small font sizes.
This was caused by glyph bitmaps having different heights from each
other. (Each glyph bitmap was minimally sized to fit only the glyph
itself, and then vertically positioned during the paint phase.
Since this vertical positioning was integer based, subpixel precision
was lost and things ended up looking wonky.)
Fix this by making all glyph bitmaps be the same height so we can blit
them at the same integer y position. We use the typographic ascent from
the OS/2 table to transform the glyph coordinates.
The end result is a huge improvement visually. :^)
AK's version should see better inlining behaviors, than the LibM one.
We avoid mixed usage for now though.
Also clean up some stale math includes and improper floatingpoint usage.
Double ampersands (&&) marking in menus is meant to provide a way
to show the ampersand, since using just one would turn it
into a modifier that sets the shortcut for the next character.
Unfortunately, while the first character had a special case to avoid
marking this set, the marking was still calculated
for the second character.
The fix is rather simple: just skip then the following character!
This issue applied only to the visual part of the Menu.
The WindowServer calculation for the shortcut character is working
properly, i.e. ignores escaped ampersands.
Thicker lines are drawn by filling rectangles along the path.
Previously these rectangles used the points as their top left corner.
This patch changes it to use the points as the center of the rectangles
which makes the PixelPaint line tool feel a lot more natural. :^)
The `float => double => float` round trip seen in a couple of places
might pessimize the code. Even if it's truncated to an int in the end,
it's weird not to use the functions with the `f` suffixes when working
with single precision floats.
- Clamp the checkerboard scanline prologue length to the total width
of the (clipped) rect we're filling.
- Use fast_u32_fill() for the prologue and epilogue as well.
We now divide each scanline into prologue, aligned run, and epilogue.
Basically, we draw enough pixels one-by-one until we reach a grid
intersection. Then we draw full grid cell slices using fast memory
fills. Finally we go back to one-by-one for the epilogue.
This is roughly 2.5x faster in a microbenchmark and no longer dominates
the ImageViewer and PixelPaint resizing profiles.
The new one is way more naive and not as fancy as the old one, but it
doesn't crash when trying to draw circles.
This algorithm just sweeps the angles required by the call, makes sure
each segment is at most 1 (pixel) long and just uses the standard
parameterization to find the coordinates of each point on the ellipse.
Problem:
- `static` variables consume memory and sometimes are less
optimizable.
- `static const` variables can be `constexpr`, usually.
- `static` function-local variables require an initialization check
every time the function is run.
Solution:
- If a global `static` variable is only used in a single function then
move it into the function and make it non-`static` and `constexpr`.
- Make all global `static` variables `constexpr` instead of `const`.
- Change function-local `static const[expr]` variables to be just
`constexpr`.
This adds a function to draw a circle specified by a center point (
relative to the given Rect) and a radius. The circle arc is only drawn
inside the specified Rect as to allow for circle arc segments.
Technically this was already possible using draw_elliptical_arc(), but
the algorithm is quite involved and lead to wonky arcs when trying to
draw circle arc segments.
The checkerboard pattern used in transparency backgrounds was sometimes
misaligned with the grid. This happened because it was incorrectly
anchoring the pattern to the clipped rect instead of the global
grid of the underlying paint target.
