system/serenity
system/serenity
1
0
Fork 0
mirror of https://github.com/SerenityOS/serenity synced 2024-11-03 03:29:38 +00:00
Code Issues Projects Releases Packages Wiki Activity
serenity/Documentation/HighDPI.md
Nico Weber d551263b11 LibGfx: Make it possible to apply an (integer) scale to a Painter 
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.
2021-01-12 23:32:54 +01:00

2.4 KiB
Raw Blame History

HighDPI design

Background

  • macOS: Only integer scale factors at app level. Can stretch final composited framebuffer at very end for non-integer display scales.

    • advantages: simple programming model, still fairly flexible; scaling at end produces coherent final image
    • disadvantages: needs 4x memory even for 1.5x scale; scaling at very makes final image less detailed than it could be

  • Android: Many (but discrete) scale levels (ldpi (0.75x), mdpi, hdpi (1.5x), xhdpi (2x), xxhdpi (3x), xxhdpi (4x))

  • Windows: has "not recommended" free form text entry for scale factor between 100% and 500%.

Integer scale factors are needed in any case so let's get that working first. Actually, let's focus on just 2x for now.

Desired end state

  • Window and Widget rects are in "logical" coordinates, which is the same as pixels at 1x scale
  • Same for mouse cursor
  • 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

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.

  1. Add some scaling support to Painter. Make it do 2x nearest neighbor scaling of everything at paint time for now.
  2. 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).
  3. 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.)
  4. Let apps opt in to high-res window framebuffers, and convert all apps one-by-one
  5. Remove high-res window framebuffer opt-in since all apps have it now.

We're currently before point 1.