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.
