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.
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.
There are a few places in the system where this could be useful,
such as PixelPaint and the MandelBrot demo. It seems general enough
that it is probably useful to have it as a system-wide cursor rather
than loading it manually each time.
This can be used immediately in PixelPaint (separate commit), but
I am adding this as a system-wide cursor since it may also be useful
for other applications that want to use it.
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 allows you to ask the color to recommend either white/black
as a contrasting text color if you were using the color as the
background. This uses the previously added luminosity() method.
Add a new Color category to the Filter menu. Add the Grayscale
filter under Filter->Color to turn the selected layer to grey colors.
Created GrayscaleFilter.h. Modify Filter.h to allow filters
without parameters.
Shades are colors darker than the color, tints are colors lighter.
This is helpful in places where we need a bunch of similar colors
with some small differences.
The common thin-cap button look (1px highlight, 2px shadow) looks nice
on regular buttons, but the scrollbar didn't feel quite right.
This patch adds 1px of offset to the highlight, giving it a thick-cap
look (which I have named Gfx::ButtonStyle::ThickCap) :^)
Non-printable characters should always have a width of 0. This is not
true for some characters like tab, but those can be exempted as the need
arises. Doing this here saves us from a bunch of checks in any place
that needs to figure out glyph widths for text which can contain
non-printable characters.
When entering FastBoxBlurFilter::apply_single_pass(), we VERIFY that the
bitmap format is BGRA8888.
This invariant allows us to use get_pixel<BGRA8888>() instead of the
generic get_pixel() throughout the function. This removes a lot of
branches and makes the filter significantly faster. :^)
The issue was that size_in_bytes() returns size_t, but the buffer used
a size of the unsigned for itself, which only matched on 32-bit
systems and caused an assert error otherwise.
This fixes a crash on drag in FileManager on non 32-bit systems!
LibTTF has a concrete dependency on LibGfx for things like Gfx::Bitmap,
and LibGfx has a concrete dependency in the TTF::Font class in
Gfx::FontDatabase. This circular dependency works fine for Serenity and
Lagom Linux builds of the two libraries. It also works fine for static
library builds on Lagom macOS builds.
However, future changes will make Lagom use shared libraries, and
circular library dependencies are not tolerated in macOS.
