I just ran through successfully building and running SerenityOS under
macOS. I ran into two main things that I struggled with, which were
- properly enabling osxfuse (through System Preferences)
- running the suggested command about compiler versions in such a way
that would be compatible with Ninja (as it turns out, I just needed
to add `-G Ninja` to the command)
This commit clarifies those things for anyone who may follow
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.
For now, only support 1x and 2x scale.
I tried doing something "smarter" first where the UI would try
to keep the physical resolution constant when toggling between
1x and 2x, but many of the smaller 1x resolutions map to 2x
logical resolutions that Compositor rejects (e.g. 1024x768 becomes
512x384, which is less than the minimum 640x480 that Compositor
wants) and it felt complicated and overly magical.
So this instead just gives you a 1x/2x toggle and a dropdown
with logical (!) resolutions. That is, 800x600 @ 2x gives you
a physical resolution of 1600x1200.
If we don't like this after trying it for a while, we can change
the UI then.
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 :^)
This adds a scale factor to Painter, which will be used for HighDPI
support. It's also a step towards general affine transforms on Painters.
All of Painter's public API takes logical coordinates, while some
internals deal with physical coordinates now. If scale == 1, logical
and physical coordinates are the same. For scale == 2, a 200x100 bitmap
would be covered by a logical {0, 0, 100, 50} rect, while its physical
size would be {0, 0, 200, 100}.
Most of Painter's functions just assert that scale() == 1 is for now,
but most functions called by WindowServer are updated to handle
arbitrary (integer) scale.
Also add a new Demo "LibGfxScaleDemo" that covers the converted
functions and that can be used to iteratively add scaling support
to more functions.
To make Painter's interface deal with logical coordinates only,
make translation() and clip_rect() non-public.
I have a local branch that gets us past implementation stage 1
in this doc, and it seems like a useful enough checkpoint to
upstream it and then iterate in tree.
* Add SERENITY_ARCH option to CMake for selecting the target toolchain
* Port all build scripts but continue to use i686
* Update GitHub Actions cache to include BuildIt.sh
We already have installation instructions for ubuntu but not yet for
Debian. Gcc-9 is not available on Debian stable so instructions for
switching to and from Debian testing are added.
Gcc 8.3.0 (which is the current version in debian 10 stable) seems to
fail at building AK. New people might get stuck when they try to run
make inside the ./Build folder and fail at building serenity.
It seems that new people go to the build instructions from the main
README, don't see Windows and are then stuck.
We do have instructions for Windows, but they aren't noted in the build
instructions, so new people get stuck thinking there's no way to build
on Windows.
Inspired by #3047, and my struggles to understand how cmake is supposed to work ^^
Thanks to @bgianfo, who made me realize that ninja can be used just like make.
No idea why I didn't notice that earlier.
This now descibes how to get the regular `make run` workflow to work
under Windows using native QEMU. It describes how to override the QEMU
binary path, as well as overriding the SerenityOS disk image file
location with a native Windows path.
Also fixes some minor spelling and punctuation issues.
