This replaces the usage of `rounded_int_rect`, whose name did not
accurately reflect the rounding operation happening. For example, the
position of the rect was not rounded but floored, and the size was
pulled through `roundf` before casting to `int` which could result in
inadvertent flooring if the resulting floating point could not exactly
represent the rounded value.
There was an off-by-one bug in `Painter::do_draw_scaled_bitmap` where
the last column and row of the source bitmap would be skipped. This was
especially visible in PixelPaint when zooming in and out on smaller
images.
Instead of the top/left of the pixel, we now use the bottom/right side
of the pixel as a threshold to stop drawing.
There's really no reason to use doubles here, except at the time I
wanted to use doubles everywhere in CSS. I now realize that is
excessive, so everything can be floats instead.
This helps make the overall codebase consistent. `class_name()` in
`Kernel` is always `StringView`, but not elsewhere.
Additionally, this results in the `strlen` (which needs to be done
when printing or other operations) always being computed at
compile-time.
`static const` variables can be computed and initialized at run-time
during initialization or the first time a function is called. Change
them to `static constexpr` to ensure they are computed at
compile-time.
This allows some removal of `strlen` because the length of the
`StringView` can be used which is pre-computed at compile-time.
C++20 provides the `requires` clause which simplifies the ability to
limit overload resolution. Prefer it over `EnableIf`
With all uses of `EnableIf` being removed, also remove the
implementation so future devs are not tempted.
Use different specified radii for the two seperate passes.
The gaussian approximation is not changed to accept two parameters since
the math is not exactly straight forward and therefore something for a
later patch. For now, let's progress!
It isn't sensible to have a negative radius for blurring, so an unsigned
value is the right thing to do here.
Now we have to cast the radius to int a few times when actually doing
the calculations but I'm sure that can be done more intelligently, but
that optimization is a thing for the future.
It looked very goofy for the two different ways of invoking the Filter
to have differently signed arguments.
PBM, PGM, and PPM image loaders are mostly common. The only difference
is how the data is read and the associated magic numbers. The magic
numbers are already made common using the loading contexts. Now make
the implementations common via a class template which accepts the
context to disambiguate.
Much of the code in PBM, PGM, and PPM image loaders is common. The
contexts are nearly identical. Instead of writing multiple contexts,
write 1 with a template argument to pass in the details of the given
format.
When doing viewbox transforms, elliptical always had large arc and
sweep flag set to false. Preserve these flags so they can be set
correctly when applying viewbox transformations.
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.
Currently, disabled text colors are hardcoded. They look good in Default
and light themes, but no so good in dark ones. This PR adds new
variables for all themes to correctly display disabled text.
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.
`CharacterBitmap` instances are generated at run-time and put on the
heap, but they can be created in a `constexpr` context and stored in
static memory.
Also, remove additional `width` and `height` `static` values in favor
of using the `constexpr` member functions of `CharacterBitmap`.
These changes also include the removal of some initialization code
which tests if the `CharacterBitmap` is created since it is always
created and removes function-local `static` values which cause
run-time branches to ensure it is initialized each time the function
is called.
There is nothing in the `Size` class which cannot be `constexpr`, but
without it being `constexpr` it prevents other things from being
`constexpr`-capable.
`Gfx::Vector[2,3,4]` are nearly identical implementations. This code
redundancy does not follow the DRY (Don't Repeat Yourself) principle
leading to possible out-of-sync errors between the classes.
Combining these classes into a class template which can be specialized
for each needed size makes the differences obvious through
`constexpr-if` blocks and `requires` clauses.
This allows bitmap font lookup to return the best matching size instead
of failing completely. The previous behavior (exact matches only)
remains the default.
This shape is for use by the main widget of a frameless window
that still wishes to have proper borders but no title.
Raised Containers were used previously for this pattern but did not
always represent perspective and shadow correctly depending on thread
highlighting and the immediate background color. Containers are
really meant to be used inside other widgets where the background
color can be controlled.
Fonts now provide their preferred line height based on maximum
height and requested line gap. TTFs provide a preferred line gap
from table metrics while BitmapFonts are hardcoded at the previous
default for now.
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.
