Hi!
Some thoughts about this:
First of all, I find it a bit strange to want to work on this now, as we
still don't have multi monitor support. I think it will make it difficult
to identify all the problems with using multiple screens with widely
different DPIs, if we can't do any testing.
Second, I already mentionned that in the linked discussion I think, your
proposal dives directly into technical and developer-oriented things. But
the main problem here is user centric, and that's something we should keep
in mind. I like the current system because it is simple to use for users.
There is a single place to configure the UI scale (you just set a font size,
and everything scales accordingly). In your proposed system it would, I guess,
be moved from appearance preferences to screen preferences. Should we still
allow users to change their font size? If so, we'll now have two places to
change the UI scaling, which I think is not as good for users.
For developers it doesn't change much: you still should get the final scaling
from one single place. But, will it be the case? Do you get it from BScreen,
or do you get it from BFont? Also, whaht happens when a window is shown in
two screens at the same time? (either because you're using "clone" mode on
two displays with different resolutions, or because you're moving a window
from one display to another and it's somewhere in the middle). I currently
don't understand how this will work with layout, Invalidate and Draw calls
(since all of these work in pixels). I think the window will be in some kind
of "split brain" state and have two halves drawn completely separately, with
completely different layouts, which seems complicated to do; or maybe it would
keep the scale of one display and draw everything using that, which will be
noticeable by the users (the window suddenly scales up or down when you move
it from one screen to another).
Third, you start by stating a problem which is that a lot of things don't
scale linearly (in particular at small font sizes), then go on with a
proposal that does not tackle this problem. We will still have to have
a min() call to have a reasonable border around text at small font sizes.
Probably we need a max() too at larger font sizes. We have to keep in mind
that UI scaling must be non-linear, and the empty space does not need to
scale with the text. I think this is the main thing to handle at the moment
(since we don't have multi monitor support anyway).
Other than that, your proposal is fine. It just moves where the scaling factor
is stored, instead of being the font size, it will be some per-screen "density".
I also should mention that app_server already store settings per screen (for the
resolution and color depth) using the screen make and model as well as its
serial
number if available (all retrieved using EDID). So at least this part will not
be
a problem.
--
Adrien.
