There are several of us in this thread that argue for the use of a scaling factor variable that drives the UI scaling. That variable can then be driven by any metric or combination of metrics, like DPI, user selected scaling or font.
As you pointed out, at least it needs to be per screen for multi monitor usage. I suggested the “Be way” might be to be able to scale it per workspace, like with resolution and color dept. For me, the natural place to put scaling preferences is in Screen preferences together with resolution and color depth, and those are set per workspace, with the default being all workspaces.
I’ll refer back to my suggestion - it font size becomes DPI aware, wouldn’t most already existing font-size scaled apps be ready to go? (they might need to receive a notification that the font size changed when moving between monitors if possible)
The only other options I can think of (all of them being more complicated) are:
Using desktop composition, draw windows to an in-memory buffer, scale them afterwards. Major drawbacks would be increased memory usage, horrible blurry graphics with DPI values that aren’t a multiple of 96. This is Windows’ “System” scaling
Scale positions/dimensions of every drawing operation. Drawbacks would be visual glitches.
Using desktop composition, combine the two approaches: scale drawing to the first multiple of 96DPI that is no smaller than the screen DPI, then scale down the image to the actual DPI. Might produce less visual glitches but somewhat blurry graphics with DPI values that aren’t a multiple of 96. This is Windows’ “System (Enhanced)” scaling, AKA GDI Scaling.
Only handle things that are drawn by the OS and let the applications to fend off for themselves. No blurriness (unless the application itself introduces so by drawing stretched bitmap graphics) and allows for pixel perfect graphics, but has the major drawback that all applications/frameworks must be modified to support querying the DPI value and scale everything accordingly. This is Windows’ “Application” scaling.
Windows itself combines various scaling options on a per-app basis, with the added complication of some applications being DPI aware, but not mixed-DPI aware, so it need another type of scaling when moved to a monitor other than the main one. Being able to restrict most DPI-awareness logic to font would make everything much simpler.
They are not DPI-aware because they were not made DPI-aware. The code that draws them will have to be changed whatever the ultimate source of the scaling factor is, font size or not. So, I don’t particularly see how that is a point either way on the question of using font size as the factor.
Yes, it happened probably on the mailing list, the forum, or the IRC channel (or maybe several of them over a period of time). But you will have to search the history of these all to find it if you don’t trust us.
Moving this discussion into the next phase: I’ve just sent a (long) post to the mailing list about HiDPI strategies with some concrete proposals about where to go from here to the development mailing list.
Just wondering: has anything be done to improve scaling in the new Haiku betas? Just tried the latest beta 5 and here are some notes (on default 3000x2000 resolution of the Surface Book):
some texts don’t seem to scale when updating the system’s font sizes: for eg. the column headers (“name”, “size”,…) and status bar at the bottom in the file manager (Tracker ?) stay tiny, even after restarting these apps
the mouse cursor doesn’t scale either and is way too small
the small status icons in the deskbar (showing battery, network status,…) don’t scale
the scrollbar arrows don’t scale enough and appear too small (especially when compared to other UI buttons: for eg. window close button)
WebPositive default font also stays tiny
This makes Haiku really difficult to use in anything but small DPI screens.
Severall bugs and such were fixed between the last two betas, but indeed we are not finished.
Don’t think i saw someone mention the deskbar icons before.
For the scrollbar issue, do you have a screenshot? Does it look the same when compared to StyledEdit? (which I think should work properly currently).
It might be applications incorrectly using the old margin constants instead of the decorator api.
Except, some users, such as myself have to set the multiple font sizes every time I plug my removable SSD with Haiku into my living room minipc connected to a 4K TV, then set them again when I plug it into my notebook with an 1280 screen, and once again when I plug it into the office PC at my workplace. And that’s just 10 percent of the hassle. I need to then adjust the desktop icon size, application icon sizes in the Deskbar, and if I could, the default icon sizes for other folders. But I can’t because there’s no such option in Tracker, or at least I find none, so instead, I have to set the icon sizes in every individual folder over and over again. Then set the font sizes in apps that have their own font settings (like Terminal). And after all these, still uncontent with the look of non-scaling UI-elements (like bevels, for example).
Also it’s worth noting that an automatically chosen font size based on DPI value may be a generally good idea, but that’s not what I as a user want. I don’t want the text to have the same physical size on my big TV screen as on my tiny phone screen because I don’t watch them from the same distance. I want them to be the same, or approximately the same, apparent size (so both are legible from the distance I look at them), not the same size measured on the surface of the screen. Since there’s no way for the system to figure from what distance I intend to use a particular display, it totally needs to be a user-provided preference. Completely independent from display DPI.
All these things should scale automatically with the font size (and they do for me); Tracker and Deskbar now store the “unscaled” sizes of all of these things and apply the scaling based on the font size. Is that not working for you? (I think this was implemented between beta4 and beta5.)
Terminal ought to do something differently here, yes. That’s certainly a bug or at least missing feature.
This is a bug that we need to fix.
And it is: it’s the font size.
It sounds like what you want is something more like per-screen font sizes. We will eventually need that for mixed-DPI systems anyway, but one install that gets booted on multiple machines is basically the same usecase here.
I think it is your assumption (in the parentheses) that is wrong. Don’t think bad layout as the look of an individual button but the look of the whole window layout. For example, imagine a font selection button that has its label written in the selected font. Given a specific font-size, the size of the button will change with the selected font, which in turn affects (or should) the content of the entire window. This is because font sizes don’t translate consistently to text-height in pixels across different fonts. It would be much more preferable if the user could provide his own preference on the UI size, a matching font-size would be chosen automatically to fit, and then used the same way to render the controls as is used now.
It is beta5. The application icons in Deskbar and menus indeed seem to scale with the font, and what I didn’t notice first, but you’re absolutely right about, the Desktop icons also scale with the font*. (which font? There’s four that we can set. It’s source for some ambiguity.) Apparently that’s not what I was expecting and found the scaling insufficient. I guess the reason is that text is a hi-contrast (monochrome) by nature, so less scaling is sufficient to keep it legible even from a distance, but the complex graphics of icons require somewhat more scaling for the same effect. This raises a question: is it the proper approach to scale “everything” based on text size only. (*btw, having the icon size described in the selection menu as 32x32, 40x40, etc. while that’s not even the final rendering size is kind of misleading.)
The problem with font size (or one of the problems), in my opinion is granularity. One would probably prefer a smoother control on the scaling factor. (Then let the system choose a matching font size.) Another problem, just to name another, is its inpredictable nature. For example, it would feel logical that a 18 pt font from a 12 pt would result in 1.5x scaling, but it is not the case at all. It all depends on the font program and also the rendering settings (hinting, etc), probably the display DPI as well. A particular font may decide that it should render the exact same size from 6 pt to 16 pt while the user would still prefer to change the gui elements nonetheless (due to touch screen control and chunky fingers, for instance). It is an extreme example with such a misbehaving font, but the effect is present in almost any font program in existence. 2+2 is almost never 4 when it comes to typography.
In summary, I think my present struggles could be solved simply by a theme manager, without disturbing the way the system works currently. Perhaps an automated one which could be activated by some trigger event (detection of specified display ID, location, whatever). I would somehow still prefer to detach the font settings from the UI size preferences, which would provide more flexibility, in my opinion.
It may for the particular font in use but you can’t depend on that. My point is that font sizes are not linear. More precisely the translation from points to pixels is not linear. 24 pt is almost never the double the height of 12 pt. Because of hinting and whatnot. Windows have a workaround for this, when you provide a negative font size, which is interpreted as pixels, rather than points. I don’t know if Haiku’s font selector or the font renderer has this feature, but I think this “backwards” approach would work better. It would be better if the user could control his preferred scaling, then the system would choose the font size for it, rather than scaling the UI based on the font size. This feels more direct and more logical.