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.
It was previously using draw_tiled_bitmap, which always aligns the
tiles with the global origin and does not respect the alpha of the
source. Switch to a new Painter::blit_tiled helper which uses
Painter::blit under the hood, which has more correct behavior.
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
This adds a new structure 'Typeface' to the FontDatabase that
represents all fonts of the same family and variant.
It can contain a list of BitmapFonts with varying size but of
the same family and weight or a pointer to a single TTF font
for all sizes of this Typeface.
