This is the same as calling FileSystemPath(foo).string(). The majority of
clients only care about canonicalizing a path, so let's have an easy way
to express that.
This patch makes it possible to draw_text() things like "ABC\nDEF\nGHI".
It works by breaking the string into lines, then computing a bounding rect
for all the lines, and finally aligning each line appropriately within
the bounding rect and drawing them one by one.
Fixes#297.
Instead of computing the path length inside the syscall handler, let the
caller do that work. This allows us to implement to new variants of open()
and creat(), called open_with_path_length() and creat_with_path_length().
These are suitable for use with e.g StringView.
Painter gains the ability to draw lines with arbitrary thickness.
It's basically implemented by drawing filled rects for thickness>1.
In PaintBrush, Tool classes can now override on_contextmenu() to
provide a context menu for the toolbox button. :^)
d66fa60fcf introduced the use of a timer
to coalesce screen updates. This is OK, but it does introduce update
latency.
To help mitigate the impact of this, we now have a second (immediate)
timer. When a compose pass is first triggered, the immediate timer will
allow the compose to happen on the next spin of the event loop (so, only
coalescing updates across a single event loop pass). Any updates that
trigger while the delayed timer is running, though, will be delayed to
that (~60fps) timer.
This fixes#103.
This makes out-of-tree linking possible. And at the same time, add a
CMakeToolchain.txt file that can be used to build arbitrary cmake-using
applications on Serenity by pointing to the CMAKE_TOOLCHAIN_FILE when
running cmake:
-DCMAKE_TOOLCHAIN_FILE=~/code/serenity/Toolchain/CMakeToolchain.txt
Use a GCC #pragma to always optimize the Painter code with -O3.
This code is performance critical and hotter than anything else in the
system, and this helps quite a bit.
The 2x, 3x and 4x upscaling fast paths benefit greatly from this.
Iterate over the source image instead of the destination image, and blow it
up pixel by pixel. This code will only run for upscaling so we don't need
to worry about anything else.
When both the x and y scale factors are integers, we can avoid a whole bunch
of the pixel lookups in the source image.
This makes 2x scaling a 320x200 bitmap another ~25% faster. :^)
Use templates to specialize draw_scaled_bitmap() so we don't have to blend()
for source without alpha, and also inline the GraphicsBitmap::get_pixel()
logic so we don't have to branch on the bitmap format on every iteration.
This is another ~30% speedup on top of the previous changes. :^)
