Problem:
- `static` variables consume memory and sometimes are less
optimizable.
- `static const` variables can be `constexpr`, usually.
- `static` function-local variables require an initialization check
every time the function is run.
Solution:
- If a global `static` variable is only used in a single function then
move it into the function and make it non-`static` and `constexpr`.
- Make all global `static` variables `constexpr` instead of `const`.
- Change function-local `static const[expr]` variables to be just
`constexpr`.
This commit unifies methods and method/param names between the above
classes, as well as adds [[nodiscard]] and ALWAYS_INLINE where
appropriate. It also renamed the various move_by methods to
translate_by, as that more closely matches the transformation
terminology.
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 *
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.
A window repaint may change the alpha value, resulting in a different
hit test outcome. In those cases, re-evaluate the cursor hit testing
after a window was painted, and update the cursor if needed.
I honestly don't know the internals of all this and what exactly is
going on, but this fixes compositing of the fullscreen window. By trial
and error I found that specifically m_invalidated_all needs to be set to
false, so it's probably different behaviour in prepare_dirty_rects(),
which depends on that...
Either way, the code composing all windows in non-fullscreen mode calls
Window::clear_dirty_rects() for each, so not doing that for the fullscreen
window as well seems like an oversight.
Fixes#4810.
We only cleared the area not covered by the backing bitmap if a
rendering rectangle intersected with the backing bitmap. But because
we are potentially calling the render function many times we need
to always clear the area not covered by the backing bitmap, whether
it intersects or not.
Fixes#5291
This implements simple window shadows around most windows, including
tooltips. Because this method uses a bitmap for the shadow bits,
it is limited to rectangular window frames. For non-rectangular
window frames we'll need to implement a more sophisticated algorithm.
This only renders the window frame once until the size of the window
changes, or some other event requires re-rendering. It is rendered
to a temporary bitmap, and then the top and bottom part is stored
in one bitmap as well as the left and right part. This also adds
an opacity setting, allowing it to be rendered with a different
opacity.
This makes it easier to enhance window themes and allows using
arbitrary bitmaps with e.g. alpha channels for e.g. shadows.
This was done with the help of several scripts, I dump them here to
easily find them later:
awk '/#ifdef/ { print "#cmakedefine01 "$2 }' AK/Debug.h.in
for debug_macro in $(awk '/#ifdef/ { print $2 }' AK/Debug.h.in)
do
find . \( -name '*.cpp' -o -name '*.h' -o -name '*.in' \) -not -path './Toolchain/*' -not -path './Build/*' -exec sed -i -E 's/#ifdef '$debug_macro'/#if '$debug_macro'/' {} \;
done
# Remember to remove WRAPPER_GERNERATOR_DEBUG from the list.
awk '/#cmake/ { print "set("$2" ON)" }' AK/Debug.h.in
blit() calls draw_scaled_bitmap() behind the scenes in scaled contexts,
and that doesn't like src_rect to be outside of the source bitmap's
bounds. Implicitly clip with the source rect, like the non-scaled
codepath already does.
Fixes#5017 even more.
Consider
draw_scaled_bitmap({0, 0, 10, 10}, source, {0, 0, 5, 5}).
Imagine wanting to split that up into two calls, like e.g. the
compositor when redrawing the background with damage rects. You really
want to be able to say
draw_scaled_bitmap({0, 0, 5, 10}, source, {0, 0, 2.5, 5})
but up to now you couldn't. Now you can.
This makes painting very low-res images (such as tile.png) in mode
"stretch" work much better.
It's less code, and blit() already handles scaled painters.
Fixes the window server asserting in highdpi mode with a centered
background image. Part of #5017.
draw_scaled_bitmap() has a clearer API (just source and dest rects --
blit_scaled() took those and scale factors and then ignored width and
height on the source rect and it was less clear what it was supposed to
do), and they do mostly the same thing.
The draw_scaled_bitmap() API takes an IntRect as source rect, so it's
currently not always possible to split a big draw_scaled_bitmap() into
two (or more) smaller draw_scaled_bitmap() calls that do the same thing
-- that'd require FloatRects. The compositor kind of wants this to be
possible, but there's already a FIXME about this not looking quite right
with the previous approach either.
draw_scaled_bitmap() handles transparent sources, so after this change
wallpapers with transparency will be blended instead of copied. But that
seems fine, and if not, the Right Fix for that is to remove the alpha
channel from wallpapers after loading them anyways.
As an added bonus, draw_scaled_bitmap() already handles display scale,
so this fixes window server asserts for background images that are shown
as "stretch" (#5017). The window server still asserts for "tile" and
"offset" for now though.
Calling draw_scaled_bitmap() here exposed a bug in it fixed by #5041.
Before that is merged, this change here will cause smearing on the
background image when moving windows around.
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.
This option was renamed from scaled to stretch in DisplaySettings in
699ba84, but since WindowServer receives a plain string and was not
updated, it wouldn't recognize the new renamed value as a valid option.
Turns out sending plain strings via IPC and only mapping them to enum
values on the receiving end is brittle, we should probably update
Desktop::set_wallpaper_mode() to use an enum as well at some point.
Fixes#5006.
Now, `chres 640 480 2` can set the UI to HighDPI 640x480 at runtime. A
real GUI for changing the display factor will come later.
(`chres 640 480 2` followed by `chres 1280 960` is very fast since
we don't have to re-allocate the framebuffer since both modes use
the exact same number of physical pixels.)
It's in efficient, and it also meant we wouldn't reallocate a bigger
backing bitmap in a lowdpi->highdpi transition, leading to minor drawing
glitches after such a transition.
(Whoops!)
Almost all logic stays in "logical" (unscaled coordinates), which
means the patch is small and things like DnD, window moving and
resizing, menu handling, menuapplets, etc all work without changes.
Screen knows about phyiscal coordinates and mouse handling internally is
in physical coordinates (so that two 1 pixel movements in succession can
translate to one 1 logical coordinate mouse movement -- only a single
event is sent in this case, on the 2nd moved pixel).
Compositor also knows about physical pixels for its backbuffers. This is
a temporary state -- in a follow-up, I'll try to let Bitmaps know about
their intrinsic scale, then Compositor won't have to know about pixels
any longer. Most of Compositor's logic stays in view units, just
blitting to and from back buffers and the cursor save buffer has to be
done in pixels. The back buffer Painter gets a scale applied which
transparently handles all drawing. (But since the backbuffer and cursor
save buffer are also HighDPI, they currently need to be drawn using a
hack temporary unscaled Painter object. This will also go away once
Bitmaps know about their intrinsic scale.)
With this, editing WindowServer.ini to say
Width=800
Height=600
ScaleFactor=2
and booting brings up a fully-functional HighDPI UI.
(Except for minimizing windows, which will crash the window server
until #4932 is merged. And I didn't test the window switcher since the
win-tab shortcut doesn't work on my system.) It's all pixel-scaled,
but it looks pretty decent :^)
