We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
This change implements a flood fill algorithm for the Bitmap class. This
will be leveraged by various Tools in PixelPaint. Moving the code into
Bitmap reduces the duplication of the algorithm throughout the
PixelPaint Tools (currently Bucket Tool and Wand Select).
The flood fill function requires you to pass in a threshold value (0 -
100) as well as a lambda for what to do when a pixel gets reached. The
lambda is provided an IntPoint representing the coordinates of the pixel
that was just reached.
The genericized lambda approach allows for a variety of things to be
done as the flood algorithm progresses. For example, the Bucket Tool
will paint each pixel that gets reached with the fill_color. The Wand
Select tool wont actually alter the bitmap itself, instead it uses the
reached pixels to alter a selection mask.
This will be needed so we can apply filter effects to the backdrop
of an element in LibWeb.
This now also allows getting a crop of a bitmap in a different format
than the source bitmap. This is for if the painter's bitmap does not
have an alpha channel, but you want to ensure the cropped bitmap does.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
This function returns an Optional<Color> and is given an
alpha_threshold. If all pixels above that alpha threshold are the
same color, it returns the color, otherwise it returns an empty
optional.
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.
The spec had its first stable release today, so I figured we should
support it as well!
As usual, by using the regular LibGfx image decoder plugin architecture,
we immediately get support for it everywhere: ImageViewer, FileManager
thumbnails, PixelPaint, and (with a small change in the subsequent
commit) even the Browser :^)
... and bring it back to try_load_from_file().
Prior to this change, changing the scaling option to x2 in the Display
Settings resulted in the following crash:
WindowServer(15:15): ASSERTION FAILED: bitmap->width() % scale_factor
== 0 ./Userland/Libraries/LibGfx/Bitmap.cpp:126
That was caused by two minor overlooked yaks:
- First, Bitmap::try_load_from_fd_and_close() tried to respect your
scale factor.
While requesting a bitmap from file can make a switcheroo to give you
a higher resolution bitmap, doing the same when you already have an fd
might violate the unveil agreement.
... but, it didn't do that.
It read bitmaps from requested fds, but also pretended all system
bitmaps in /res/ are the HiDPI ones when you enabled that mode.
- d85d741c59 used this function to deduplicate try_load_from_file().
It actually made this bug a lot easier to replicate!
Closes#10920
This also allows us to get rid of the ShareableBitmap(Bitmap)
constructor which was easy to misuse. Everyone now uses Bitmap's
to_shareable_bitmap() helper instead.
Making a bitmap non-volatile after being volatile may fail to allocate
physical pages after the kernel stole the old pages in a purge.
This is different from the pages being purged, but reallocated. In that
case, they are simply replaced with zero-fill-on-demand pages as if
they were freshly allocated.
This was a really weird thing to begin with, purgeable bitmaps were
basically regular bitmaps without a physical memory reservation.
Since all the clients of this code ended up populating the bitmaps
with pixels immediately after allocating them anyway, there was no
need to avoid the reservation.
Instead, all Gfx::Bitmaps are now purgeable, in the sense that they
can be marked as volatile or non-volatile.
The only difference here is that allocation failure is surfaced when
we try to create the bitmap instead of during the handling of a
subsequent page fault.
Instead of using a low-level, proprietary API inside LibGfx, let's use
Core::AnonymousBuffer which already abstracts anon_fd and offers a
higher-level API too.
This cuts a region of a bitmap specified by the provided Gfx::IntRect
and returns it. Areas outside of the bounds of the original bitmap are
filled in with black.
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 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.
(...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.
Bitmap::load_from_file("foo.png", 2) will now look for "foo-2x.png" and
try load that as a bitmap with scale factor 2 if it exists. If it
doesn't, it falls back to the 1x bitmap as normal.
Only places that know that they'll draw the bitmap to a 2x painter
should pass "2" for the second argument.
Use this new API in WindowServer for loading window buttons and
cursors.
As a testing aid, ctrl-shift-super-i can force HighDPI icons off in
HighDPI mode. Toggling between low-res and high-res icons makes it easy
to see if the high-res version of an icon looks right: It should look
like the low-res version, just less jaggy.
We'll likely have to grow a better API for loading scaled resources, but
for now this suffices.
Things to check:
- `chres 640 480` followed by `chres 640 480 2` followed by
`chres 640 480`
- window buttons in window context menu (in task bar and on title bar)
still have low-res icons
- ctrl-shift-super-i in high-res mode toggles sharpness of window
buttons and of arrow cursorf
- arrow cursor hotspot is still where you'd expect
Gfx::Bitmap can now store its scale factor. Normally it's 1, but
in high dpi mode it can be 2.
If a Bitmap with a scale factor of 2 is blitted to a Painter with
scale factor of 2, the pixels can be copied over without any resampling.
(When blitting a Bitmap with a scale factor of 1 to a Painter with scale
factor of 2, the Bitmap is painted at twice its width and height at
paint time. Blitting a Bitmap with a scale factor of 2 to a Painter with
scale factor 1 is not supported.)
A Bitmap with scale factor of 2 reports the same width() and height() as
one with scale factor 1. That's important because many places in the
codebase use a bitmap's width() and height() to layout Widgets, and all
widget coordinates are in logical coordinates as well, per
Documentation/HighDPI.md.
Bitmap grows physical_width() / physical_height() to access the actual
pixel size. Update a few callers that work with pixels to call this
instead.
Make Painter's constructor take its scale factor from the target bitmap
that's passed in, and update its various blit() methods to handle
blitting a 2x bitmap to a 2x painter. This allows removing some gnarly
code in Compositor. (In return, put some new gnarly code in
LibGfxScaleDemo to preserve behavior there.)
No intended behavior change.
