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

  • From: "Mr. waddlesplash" <waddlesplash@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 30 Aug 2021 19:55:58 -0400

Because it seems I left things a little less than clear in my original
message as to precisely what changes I am proposing, to recap, here is
what I am suggesting be changed:

 * BScreen gains a density factor (a float). We can call it "pixel
density" or something like that.
 * BFont also gains that same parameter.
    -  Font instantiation in app_server applies this value as part of
the DPI computation.
    - "-1" for this parameter means "use the screen the view is on's
value" when the BFont is applied into a BView. (When not applied to a
BView, -1 is the same as 1 for StringWidth etc.)
 * B_FONTS_CHANGED will be sent whenever anything that will change the
pixel metrics of a font is changed, whether that be font size or
density factors.
 * BControlLook no longer uses be_plain_font, but requires a BFont to
be passed in to whatever functions need a font (it should be the
current view's font that applications pass in.)

Parallel to whatever is done re. metrics and font sizes:

 * All applications that compute metrics by doing "font size / 12"
should not be doing that, and alternatives should be found. (In many
cases, either using one of the BControlLook Spacing methods, or adding
a new metrics computation to ControlLook should be done.)
 * Lots of new code needs to be written to handle B_FONTS_CHANGED,
even for just standard font changes at present, as nothing handles it
at all.

On Mon, Aug 30, 2021 at 7:32 PM Ryan Leavengood <leavengood@xxxxxxxxx> wrote:

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

Anything presently unscaled is merely so because it is using
hard-coded pixel values and has not yet been adjusted to scale
properly according to the font size. I will go through and work on
fixing all of that once we decide precisely how things should work
going forward, so we don't have to reimplement this at a later date
when we discover that there is some major case (e.g. multiple
monitors) it does not handle properly.

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.

Not really, we should be able to handle font size changes one way or
another "live". There is already a B_FONTS_UPDATED message same as
B_COLORS_UPDATED, but nothing does anything with it, even just in the
Interface Kit. I intend to go through and work on that as well.


Other related posts: