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

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 31 Aug 2021 16:52:23 +0200

Hi Augustin,

Am 30.08.2021 um 23:06 schrieb Mr. waddlesplash:

Returning to the question of font size and pixels: I propose that we
split the pixel size of a font from its point size. Beyond making
basic sense given the definition of "points," I note that FreeType
itself has a mechanism to account for "DPI" directly in the font size
instantiation routine, which we currently hardcode to 72 [3].

Actually, I think it would be cleaner to have a rendering context (like a BScreen) that is passed to any BFont methods that return pixel sizes.

However, I think we should at least try to make it work with our current API for now.

But that doesn't ultimately mean that BFont needs to be aware of the scaling factor (or pixel ratio, or whatever) of the screen it's supposed to be rendered on.

If it had to, it would still need to have a default ratio that would be translated to the current (ie. the application's main) screen, however, and that would open the door for many bugs in multi screen setups with different scaling factors.

Code like:
        BFont font(&be_plain_font);
        ... do font size computations ...

would become wrong in those setups.

Therefore, I think going this way might be troublesome. If an application does not support scaling its bitmaps, it will look strange, too.

Having a scaling factor applied at app_server side would be much cleaner IMO (ie. the mechanism that is already exposed by BView::SetScale()).
We should introduce BBitmap, BView, and BWindow flags to turn off automatic scaling, and that's it. Even double buffered views would look sharp with scaling then, with no changes needed at all at the application side.
We already have fractional coordinates everywhere, let's put them to use.


Other related posts: