This used to generate a warning about using a deprecated copy-assign,
default-generated by the compiler, and deprecated because we hand-
implement the copy-constructor. This warning is correct, since the
default-generated copy-assign may or may not be as efficient as memcpy.
This patch gets rid of the warning, and has either no performance impact
or a slightly positive one. If this turns out to be wrong, we should
probably also fix the copy-constructor.
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.
We were seeing a problem in LibWeb, where layout elements would be 1px
larger than they should be, due to layout positions using float values,
and then converting using `enclosing_int_rect()`. `rounded_int_rect()`
replaces that use, by maintaining the original rect's size.
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.
Removes the concept of Type enumeration in favor of a bitmask which
represents 544 potential byte ranges of 256 characters per bit,
supporting the current unicode code point set (0x0000-0x10FFFF).
Range positions are indexed in a vector for code point lookup and
conversion.
Co-authored-by: Lynn <lynn@foldr.moe>
These would cause the stack to overflow when LibWeb tried rendering a
CSS box-shadow for a large enough element.
Use Vector (with *some* inline capacity for smaller images) to avoid
this issue. If these heap allocations turn out to be too much work,
we can add something like a persistent scratch buffer cache.
Previously we only had `Point::end_point_for_square_aspect_ratio`,
which was convenient for PixelPaint but assumed the aspect ratio
was always fixed at 1. This patch replaces it with a new mthod that
takes in an arbitrary aspect ratio and computes the end point based
off that.
There's some explicit casting going on in `Point.cpp` to ensure that
the types line up, since we're templating Point based on `T`.`
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.
