Resolution indpendence

[David De La Harpe Golden]

Nicolas Mailhot wrote:

>> Nothing that exists today works at all with high-density displays -- the
>> Nokia tablets still just always smash the DPI to 96 or so, because
> 
> because bad software assumes 96dpi, and breaks otherwise.
> 
> The rest are just excuses. 

heh.


I do think it might be useful, in these days of compositing managers, to
allow per-window resolution and zoom control.

Soeren made the point about toolkits being able to find out the physical
screens dimensions for a single merged logical screen from EDID info,
would probably be the highest-quality-drawing-possible solution, but
might place too much burden on the toolkits to DTRT ?

Here's some half-formed thoughts, just as a talking point, probably old
ground to quite a few people. I'm hazy on ICCCM and wm<->toolkit comms
in general, so I may well be getting some details wrong:

*** invent a _NET_WM_PHYS_RES _window_ xproperty taking X and Y
resolution values (if they have to be integers due to x protocol things,
make them dots per hundred inches or something).

If a window gets a _NET_WM_PHYS_RES = (120.0, 120.0) or whatever
property set, then an aware toolkit just uses that preferentially to any
overall screen DPI/physical size info for that window.  When that
property is updated by the window/compositing manager, the
[resolution-independent vector gui of course ;-) ] toolkit just does an
xrandr-like adjustment for the new DPI - the major toolkits afaik
already do that for screen changes, so the code paths basically exist
already?

(I suggest resolution rather than a physical window size measurement
because it won't have to change so often under mere window reshapes).

Then, when windows are dragged from physical screen to physical screen
within the single xrandr merged logical screen, the compositing window
manager  adjusts the _NET_WM_PHYS_RES_DPI *  (and probably the pixel
size of the window, to preserve physical size).  That way, I could drag
an A4 window from one display to the next, and it would stay physically
A4 sized.
Yay!

(* finding out the individual screen physical dpis and arrangement the
"hard way" I guess by aforementioned EDIDs and/or some new user settings
So I guess this proposal does not quite obviate the need for additional
screen-level data discovery capabilities, just shifts most of the burden
onto the few compositing window managers rather than the many toolkits...)

When a window spans multiple screens (the hard case), the compositing
window manager supplies the max of the DPIs of the screens as the
xproperty (so the toolkit doesn't need to think about drawing with more
than one DPI to different regions of the same window...), and
app-transparently (presumably 3d-hardware banging) zooms out from the
rectangles for the other screens (n.b. if it doesn't do that magic
subregion rescaling for this case, hey, that's no worse than today...).
 That might require some associated input event rescaling system to work
perfectly, but I believe that's being worked on anyway...

- that way, a physically A4 sized window dragged to span parts of four
screens of different reses stays physically A4 sized (assuming properly
configured physical screen positions with dead zones for any gaps and
the like.  Hmm. That's tricky if the dead zones are measured in pixels.
Maybe also need to be able to specify the physical screens relative
positions in physical units for perfection...)

A compositing/window manager could/should supply a zoom setting and
(presumably 3d-hardware banging) zooming, so that (in particular)
resolution-unaware/legacy bitmap apps can be zoomed into WITHOUT abusing
physical resolution settings for zooming.

*** It might also be "necessary" to provide an X extension to allow a
compositing window manager to supply a _fake_ screen dpi (because that's
what non _NET_WM_PHYS_RES apps will use) to individual legacy bitmappy x
clients so that they can be forced to think the screen is 96 dpi, then
zoomed into without their awareness.

*** The compositing window manager could ALSO provide a 1:2 etc. scale
setting on a per application or per window basis, by just supplying
different _NET_WM_PHYS_RES than realistic. (and of course a default
that users can just tweak with a slider or whatever away from 1:1).

*** Or it may be better not to do that, and always keep NET_WM_PHYS_RES
realistic (except in obscure cases ++), but ALSO introduce a
NET_WM_PLEASE_SCALE_TO == 1.5 or whatever xproperty that aware toolkits
can honour.

N.B. The application-handled scaling by unrealistic PHYS_RES or
PLEASE_SCALE_TO is quite different to application-transparent zooming
being done by the compositing manager! (Duh, but just in case)

(++ One could e.g. "pixel-perfect" preview a physical-size-adaptive gui
for a small, hires display on a large 100DPI developer's workstation by
e.g. setting the window's pixel size to 640x480 and the
_NET_WM_PHYS_RES_DPI to 250,250,  "fooling" the _NET_WM_PHYS_RES_DPI
aware toolkit into thinking its drawing for the small, hires device
rather than a big, low-res device.)

Something similar might work for color profiles. Maybe.

This has problems for multi-window apps. At worst, there'd be a
potentially unsightly resize event just after an app opens another
window, BUT apps could e.g. assume the dpi of the first window they open
for subsequent windows (the common case), set the window property to
acknowledge the DPI the app thinks it is, and would only have to rescale
if the window manager then corrects it.

*** Hmmm.  Maybe there should be separate APP_REQUESTED_PHYS_RES
USER_SPECIFIED_PHYS_RES parameters (like window pixel sizes
themselves!), so that an app that knows it was made only to work
decently on a 96 dpi display can say so, as a sop to the diehard
bitmap-gui-drawers - then the compositing wm can zoom it by
default/according to user tastes on hires displays.