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

  • From: "Mr. waddlesplash" <waddlesplash@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 30 Aug 2021 18:40:51 -0400

On Mon, Aug 30, 2021 at 6:26 PM X512 <dmarc-noreply@xxxxxxxxxxxxx> wrote:

So you can set different font typefaces per screen? That makes no sense.
BScreen should provide only scaling ratio and be fully BFont
independent. Otherwise this would mix GUI system design layering.

This was explaining what we would likely have to do if we kept the
current state of things without introducing any new variables, not
what I am immediately proposing. Sorry if that was not especially

Just make it always operate in device pixels like Haiku currently does.
Use BControlLook and BLayout to calculate that device pixels values to
avoid hardcoding can manual scaling calculation. be_default_font should
be probably also replaced with `BFont BControlLook::DefaultFont()` that
will return font with suze premultiplied to scaling ratio.

Ultimately there are plenty of places where metrics computations are
going to have to occur outside BControlLook, e.g. in Tracker list
views, etc. They may well be based on BControlLook values (e.g. "item
spacing * 2" or whatever), but probably they are going to ultimately
go back to the font size.

In order to make this work, BControlLook should get information about
scaling ratio that can be retrieved by BView -> BWindow -> BScreen path.
One option would be adding BView argument to all BControlLook methods to
retrieve scaling ratio. Another option would be creating separate
instance of BControlLook for each scaling ratio and introduce some
BControlLookRoster to request BControlLook for specific
BView/BWindow/BScreen. It is also possible to get scaling ratio by TLS
variable because each BWindow have separate thread, but I think that it
is not a good idea.

Only those methods that deal with metrics directly should be passed
any new arguments under this system, and those methods should be
passed BFonts, not BViews, because the BFont objects will contain
everything needed to compute metrics.

No. It introduce serious limitation to not allow separately define UI
scaling and font size. Some users may prefer setting larger/smaller
font, but do not change UI scaling (icons/bitmaps size, padding/margins
etc.). For example BeOS use smaller font size than Haiku, but the same
other sizes. I see absolutely no sense in introducing this limitation.

This assumes that metrics are tied only to the font size or the scale
factor and nothing else. I think that is just wrong: we should add a
way to adjust metrics separately from font size or "scale factor" if
we want users to be able to do that (and I don't know that we do; we
could well decide that minority of people who want strange or unusual
metrics separate from font sizes can use custom control looks

Tightly coupling the scale factor to the font size still solves far
more problems than it causes, to say the least, and if we want a way
to adjust metrics further, we should add that totally independent of
any scale factors or font sizes. The simple fact is that the vast
majority of metrics are clearly related to the font metrics, and the
few that are not should be derived from the font metrics for
consistency's sake.


Other related posts: