letoram
High DPI support
First of all, thanks so much for developing this project, it is rare to see real innovation happening in this area, especially since lately people seem to be stuck in the echo chamber of promoting fundamentally broken protocols like Wayland.
Now this is more of a question than an issue and I am sorry if it has already been answered.
How is High DPI support coming along in Arcan? Specifically I am interested in the following points:
- Is there mixed DPI support? (support for different scaling factors per screen)?
- Is there support for fractional scaling, i.e. may the scaling factor be fractional? (Wayland is still struggling with this one after all these years, on Xorg and with Qt applications it works perfectly fine)
- Is scaling done on the client side (i.e. the application itself scales)? This is necessary for non-blurry fractional scaling. For example on most Wayland compositors, right now 1.5x scaling is done by telling the application to render at 3x, and then downscaling it at 0.5x on the compositor side, which is a total shitshow. (Unfortunately that's not even the worst design decision they made in Wayland)
- How is the scaling factor propagated to clients? (i.e. how does a client application get the scaling factor so that it can perform its scaling)
- Is it possible to change DPI during runtime? (In Xorg and with Qt this would be possible e.g. with this unmerged patch)
- How does an application handle being inbetween monitors?, i.e. if an application is dragged from one monitor to another with a different DPI, how does the application look when it's right in the middle?
I hope you don't mind giving some insight into High DPI support in Arcan, and sorry if it's been asked before but I didn't find anything. I also know that the last 2 questions are not easy to implement correctly, but I am wondering how Arcan handles these difficult scenarios. If Arcan proves to have better HighDPI capabilities than Wayland, I might try it out.
https://arcan-fe.com/2018/10/17/arcan-versus-xorg-approaching-feature-parity/ apparently the density part lacked a link, but go down to to displays, density and colour management.
Roughly put, the client, upon connecting, gets a reference font, presentation density (though in PPCM as the metric system won) and desired point size for whatever your default 'readable' size you default to. That is all that a vector rendering engine need to properly layout and raster contents. These can all be changed per window at runtime. There is also the distant possibility of pushing another window to the client requesting that it renders twice with the properties of a different window, but no client backend can deal with that. I'll return to why later.
Clients do not (and should not) reason in scale factor or similar transforms, it should just generate contents based on these set parameters. The window manager is free to lie about the building blocks, e.g. set a different target density or presentation size hint (certain font engines do present and behave differently when preparing for 8pt on a 200dpi output than it would on a 96dpi output). Should the client submit contents that does not fit these settings, the WM has all the tools needed to filter/scale/... based on where it wants to compose things - taking a 320x240 locked client emulating an old video game console and presenting on a high density screen might look best with a content aware algorithm like xBR scaling, but that happens at composition where it can be done at the lowest possible cost.
A tradeoff here is that clients, outside special circumstances (VR, Colour Management) know very little of the displays, they don't need to know - they just need "channel layout / density" (subchannel hinting for font rendering) and how much space it is allowed to use. It picks the best it can do based on that, and the rest is WM magic. Durden has a lot of tools for this (target/video/advanced, target/video/scaling, ...).
Crutch is that this is not represented in current toolkit backends, as I used wayland for legacy client compatibility and have yet to really finalize any other integration (though might eventually have to do chromium-ozone and finish Xarcan) - but those can still be worked around solely from the WM angle above or as compatibility hacks in e.g. arcan-wayland -scale -exec some-client.
presentation density (though in PPCM as the metric system won)
Hadn't thought of that, now that's much more reasonable than DPI.
Clients do not (and should not) reason in scale factor or similar transforms, it should just generate contents based on these set parameters.
Makes sense! I also just read about 3d vector output data in Shmif. If I am not mistaken that would even allow to do server side fractional scaling without loss in quality, that's pretty smart! Or you could even send the vector data over the network and then do the final rasterizing on the remote client, for lower bandwidth usage and higher output quality.
Crutch is that this is not represented in current toolkit backends, as I used wayland for legacy client compatibility
So if I understand correctly, X11 clients right now do not get the correct PPCM and always render at the same size?
Roughly put, the client, upon connecting, gets a reference font, presentation density and desired point size
Wait, so how would a user requesting a scaling factor of 1.5x reflect in those parameters? I guess the desired point size would just be multiplied with 1.5, correct?
subchannel hinting for font rendering
why...
There are enough crappy displays around for it to be relevant still, as well as eccentric displays where the value shouldn't be ruled out. In the same fashion we still correct for chromatic aberration in VR, the crazy calibrations for lenticular displays, projected stereoscopic like tilt5 and other madness) - the information is there and cheap to pass on. What could be questioned is that there is no mechanism in play for saying what was considered and not when producing buffer contents.
presentation density (though in PPCM as the metric system won)
Hadn't thought of that, now that's much more reasonable than DPI.
Clients do not (and should not) reason in scale factor or similar transforms, it should just generate contents based on these set parameters.
Makes sense! I also just read about 3d vector output data in Shmif. If I am not mistaken that would even allow to do server side fractional scaling without loss in quality, that's pretty smart! Or you could even send the vector data over the network and then do the final rasterizing on the remote client, for lower bandwidth usage and higher output quality.
Crutch is that this is not represented in current toolkit backends, as I used wayland for legacy client compatibility
So if I understand correctly, X11 clients right now do not get the correct PPCM and always render at the same size?
Roughly put, the client, upon connecting, gets a reference font, presentation density and desired point size
Wait, so how would a user requesting a scaling factor of 1.5x reflect in those parameters? I guess the desired point size would just be multiplied with 1.5, correct?
Leave the point size alone, it has an established vocabulary with the user (from word processing times you know the "size" of 12, 14 18 pt and so on). In the 1 Pixel = (dpi/72) * Point formula, scale dpi if anything since that is what will vary anyhow. The legacy trap is (win to 96, mac once to 72) to assume a constant value for dpi and the chaos ensued.