summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorNico Weber <thakis@chromium.org>2021-01-15 10:58:55 -0500
committerAndreas Kling <kling@serenityos.org>2021-01-15 19:10:16 +0100
commite87b8a79edbb1af911549c8982ac107176068fe5 (patch)
treeaae60238fbb037a523215665c0de362a53051e29 /Documentation
parent867807fb2b878f9aec8f62a44f218a3bd451ddeb (diff)
downloadserenity-e87b8a79edbb1af911549c8982ac107176068fe5.zip
WindowServer: Make HighDPI aware
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 :^)
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/HighDPI.md9
1 files changed, 5 insertions, 4 deletions
diff --git a/Documentation/HighDPI.md b/Documentation/HighDPI.md
index 0043e77a6a..885cebbd83 100644
--- a/Documentation/HighDPI.md
+++ b/Documentation/HighDPI.md
@@ -18,8 +18,8 @@ Integer scale factors are needed in any case so let's get that working first. Ac
Desired end state
-----------------
-- Window and Widget rects are in "logical" coordinates, which is the same as pixels at 1x scale
-- Same for mouse cursor
+- All rects (Window and Widget rects, mouse cursor) are in "logical" coordinates, which is the same as pixels at 1x scale, as much as possible.
+- If something needs to be in pixels, its name starts with `physical_`. Physical coordinates should as much as possible not cross API boundaries.
- Jury's still out if logical coordinates should stay ints. Probably, but it means mouse cursor etc only have point resolution, not pixel resolution
- We should have something that can store a collection of (lazily-loaded?) bitmaps and fonts that each represent a single image / font at different scale levels, and at paint time the right representation is picked for the current scale
@@ -29,9 +29,10 @@ Implementation plan
The plan is to have all applications use highdpi backbuffers eventually. It'll take some time to get there though, so here's a plan for getting there incrementally.
0. Add some scaling support to Painter. Make it do 2x nearest neighbor scaling of everything at paint time for now.
-1. Add scale factor concept to WindowServer and let DisplaySettings toggle it. WindowServer has a scaled framebuffer/backbuffer. All other bitmaps (both other bitmaps in WindowServer, as well as everything WindowServer-client-side) are always stored at 1x and scaled up when they're painted to the framebuffer. Things will look fine at 2x, but pixely (but window gradients will be smooth already).
+1. Add scale factor concept to WindowServer. WindowServer has a scaled framebuffer/backbuffer. All other bitmaps (both other bitmaps in WindowServer, as well as everything WindowServer-client-side) are always stored at 1x and scaled up when they're painted to the framebuffer. Things will look fine at 2x, but pixely (but window gradients will be smooth already).
+2. Let DisplaySettings toggle it WindowServer scale. Now it's possible to switch to and from HighDPI dynamically, using UI.
2. Come up with a system to have scale-dependent bitmap and font resources. Use that to use a high-res cursor bitmaps and high-res menu bar text painting in window server. Menu text and cursor will look less pixely. (And window frames too, I suppose.)
3. Let apps opt in to high-res window framebuffers, and convert all apps one-by-one
4. Remove high-res window framebuffer opt-in since all apps have it now.
-We're currently before point 1.
+We're currently before point 2.