[haiku-development] Re: HiDPI strategies, current and future

  • From: "Mr. waddlesplash" <waddlesplash@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 31 Aug 2021 14:08:10 -0400

On Tue, Aug 31, 2021 at 1:12 PM Adrien Destugues
<pulkomandy@xxxxxxxxxxxxx> wrote:

But it isn't solved, since we end up with two independant settings.
This is not only annoying for users, it also makes it difficult for
developers to make sure their application work in all cases.

Ideally, the Interface Kit will handle almost everything here, and
developers only need to worry about font metrics in 99% of cases, just
as before; except this time they will have to worry even less about
how to come up with font sizes relative to the default one.

Currently, you basically need to test 10pt font, 24pt font, and maybe 
something in
between, and you know if your UI works at these size, it will work all the 
time.

But if there are two separate settings, now you need to test at least 4 cases:
- Low density + small font
- Low density + large font
- High density + small font
- High density + large font

And probably some things in the middle. I think this is going to create 
problems
where some apps don't work with certain settings. Even if the layout kit does 
quite
a good job at setting size constraints, for complex apps this will always be 
a problem.

...

Well, I don't really agree. Two different settings make things complicated
and confusing for both users and developers.

Later in the email, you go on to detail cases where one might want
small controls with large fonts, or the reverse. How will this be
accomplished without two settings, then?

I think however you look at it, HiDPI or not, two settings is just
inevitable for the cases you enumerate, but HiDPI makes it a must-have
in addition to those.

We'll have to see how this works in practise. My worry here is that the
"density" is an arbitrary unit and as such feels a bit abstract to me,
and as a result, hard to reason with.

Yes, there is that. I do not know what a better one would be. "DPI" is
just not a good value to work with in general, and sizes in general
are such a subjective matter that it is hard to decide what the right
approach to take is here.

I guess what would work best in that aspect is workign either with pixels,
or some well-defined unit (typographic points, millimeters, inches,
"device independant pixels", roughly by order of preference for me). I
find it easier to work with two well defined coordinate systems than work
with a single system (pixels) and a scaling factor (density).

The problem is that resolutions and physical sizes do not correspond
in general. I may have a 20 inch monitor with 4K resolution and want a
UI that is 150% larger than normal in terms of pixels. Or I may have a
30 inch monitor with 4K resolution and want 175%. Or some user may be
hard of vision and want 150% on a 1080p screen, etc. So I agree that
this is a little hard to reason about, but I think that is because
there are so many varying reasons why larger metrics might be chosen.

The other worry is getting the info from BFont. This means the BFont object
must remember which screen it is attached to.

No, the BFont object only needs to remember what density it has, which
it does get from the screen, but there are plenty of cases where the
font may have a different density than the screen, intentionally. For
instance, a particular application may decide it wants to scale at 2x
instead of 1.5x; or any number of other cases like that. Offscreen
views may vary in density based on other things.

Now your two views actually have different fonts, possibly neither of which
is the one you defined (because they both have non-default scaling). This
ends up being a bit confusing.

As I enumerated before:
  * if you leave the default value of "-1" for "density" in fonts,
then yes, you will here wind up with two different fonts
  * if you specifically set a density on the font before applying it,
then you will have the same font in all three cases.

So I think this is less confusing than it may at first seem like it would be.

So I think I would deprecate the StringWidth and other related methods in 
BFont,
and keep only the BView version. Or at least make them work at some default
scale only. This would force developers to always do things in the context of
a given view, which will be in sync with a given screen (or other context, for
example in the case of printing).

Like I noted in my previous message: I put serious consideration to
deprecating those BFont routines, but for the reasons I enumerated, I
think it is just not a good idea to block font metrics calculation
without a BView. It would also seriously complicate existing code,
which would be a large burden to rewrite, so I do not think that this
is a decision to be made lightly if at all.

As you said, if we are redesigning the way we scale the UI, let's try to think
about all the cases, so we don't have to redesign it again later. Or at least,
know the limitations in our design choice.

Sure, but as far as I can tell from thinking about it, this is a
problem no matter which approach we take, and the approach I am here
proposing does not really affect this case much. It may make it
slightly easier to handle, even, given that multiple screens are a
design consideration in general.

I think your approach of the scaling factor blindly affecting everything
proprotionally is not going to work so well. If I understand correctly,
the font size could not be adjusted per-display in this scenario.

Indeed, the font size would not be set per-display. I guess we can
consider exposing something like that later, but for now, I think it
should not really be needed. The examples you give of especially small
or oddly proportioned displays are interesting, but is there any
better way to handle them than what is being proposed here? Maybe we
need min() and max() on computations, but I don't think the
per-display-font-sizes approach will be that much better of an
approach.

I don't know if we can find a good way to compute this, maybe it's too hard
to do and we will just have to decide which kind of display we design our
UI for, knowing that the rendering on smaller or higher resolution displays
will not be as perfect as it could be.

I think this is kind of the state we are already in, and we are now
trying to adapt things to higher-resolution displays. Whether we want
to adapt them to lower-resolution displays, too, is maybe a separate,
though closely related, question.

Having two separate settings controllable by the user may also be a way to
achieve that, but I think it will not work so well with the settings being
"font size" and "display density".

I agree that having two settings that affect UI scale is maybe not so
great. But when I think about it and go through the logic, it all
seems to add up...

I guess we need to sketch out how exactly these UI options will be
set. Per-workspace seems the right way to go, but the real question is
what we will indicate in Appearance settings that if they want to
change HiDPI options, they have to go to Screen/Workspace preferences.
That can get confusing, and I don't really know what to do about it.

However, I currently don't have a retina
display, so, it's something I can't really experiment with, even if I had
dual screen support. So I may be overengineering things here and maybe we
could get things to look ok.

Well, I am typing this from a 4K monitor, hence part of my personal
interest in working on this. :)

-waddlesplash

Other related posts: