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.
This commit adds a draw_physical_line method, which is the exact same
as draw_line, except it's parameters are already transformed and
scaled. This is used by both draw_line and draw_rect, as a slight
optimization to save some work. It also fixed draw_rect not checking
whether it should draw the lines before drawing them.
This allows the painter to be scaled separately in both directions, and
not just in integer intervals. This is crucial for proper SVG viewBox
support.
Most bitmap-related things verify the scale to be one as of now.
This commit unifies methods and method/param names between the above
classes, as well as adds [[nodiscard]] and ALWAYS_INLINE where
appropriate. It also renamed the various move_by methods to
translate_by, as that more closely matches the transformation
terminology.
This adds a *very* simplified version of the UNICODE BIDIRECTIONAL
ALGORITHM (https://www.unicode.org/reports/tr9/), that can render most
bidirectional text but also produces awkward results in a large amount
of edge cases, and as such, this should probably be replaced with a
fully spec compliant implementation at some point.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
This warning informs of float-to-double conversions. The best solution
seems to be to do math *either* in 32-bit *or* in 64-bit, and only to
cross over when absolutely necessary.
Since we first check the winding number and only then update it, fills
for "Rectangle-like" (made up of 2 parallel segments) paths would draw
nothing when filled by NonZero winding rules. (Fix by alimpfard)
This will be used by ImageData objects in LibWeb since the web spec
says these store colors in RGBA8888 order.
The only thing you can do with this format right now is blitting it
onto a BGRA8888 bitmap.
The previous names (RGBA32 and RGB32) were misleading since that's not
the actual byte order in memory. The new names reflect exactly how the
color values get laid out in bitmap data.
This fixes some precision issues in Painter::draw_triangle()
that caused the Cube demo to leave pixels empty between triangles
under certain angles.
Also adds some extra comments for clarity and early returns when
parts of the triangle do not need to be drawn.
