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

  • From: Ryan Leavengood <leavengood@xxxxxxxxx>
  • To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
  • Date: Mon, 30 Aug 2021 19:31:46 -0400

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


On 2021/08/31 6:06, Mr. waddlesplash wrote:
Clearly, coupling the "scale factor" tightly to the font size, and
having most things compute UI metrics based on the font size was a
good idea.
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.

I feel like waddlesplash has addressed some of your concerns with the
font pixel density proposal. It really sounds a lot like what you have
proposed.

With the proposed change, users can still change font size, except now
the "point" values will be more accurate as they can actually match
the screen DPI. The scaling factor could then also be adjusted to
change UI scaling, it will just happen to be implemented in terms of
the font pixel density.

I think this proposal sounds reasonable, though it is hard to see what
might be wrong with it. I've tried the current font based scaling on
my 4K screen and overall I don't like it. It is inconsistent and I
think it will require too much tweaking of various things. I'm not
sure it will work well with the browser either. On that note there is
a devicePixelRatio exposed in the browser which it sounds like the new
font pixel density would match up with nicely:
https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio

Overall here is what I want:
1. WYSIWIG font points. It should be easy to code a native word
processor with a proper print preview. Web browser font sizes should
look like other systems.
2. Consistent 1 click fractional scaling. If I scale things to 1.5x,
everything should scale up to 1.5x. Window borders, desktop icons,
Deskbar, Terminal, etc. As noted the macOS "2x or nothing" approach is
pretty limiting when you don't fully control the hardware. The current
font based approach leaves many things unscaled and is confusing. I
don't know how it is implemented but how ChromeOS does things seems
good.
3. Scale changes should happen immediately and update everything live.
This was done for colors and it should also be done for scaling. Tying
the scale factor to the font might be a downside here.

I feel like all these could be addressed by the font pixel density
proposal (maybe calling it pixel ratio makes more sense though.)
Though they could also be addressed with a general scale factor like
what X512 is proposing.

I feel like it can be hard to imagine the corner cases without seeing
the working code. Here are a few general tricky questions for any
proposal to address this issue:

- How are the window border sizes calculated? This doesn't seem
related to font size at all, but certainly the scaling factor makes it
easy to calculate and maybe so does a font pixel ratio or density.
- Someone opens a 6000x4000 pixel image in ShowImage on a 4K screen
scaled at 1.5x. How many pixels does ShowImage think it has for this
image? This seems straightforward for the waddlesplash "font pixel
ratio" proposal but less so for the X512 general scaling factor.
- I have a 24" 1080p screen at 1x and a 24" 4K screen at 2x (assuming
multiple monitors is working, of course.) I open the same PDF twice
and maximize it on each screen. It should look almost exactly the
same, except twice as clear on the 4K screen. Same thing for an image.

--
Regards,
Ryan

Other related posts: