Hi everyone.
One annoyance from other systems that I'd like to see Haiku avoid is an
overall 'scaling' factor applied unconditionally to all widgets/views. For
instance, I work in a game development house where we have a target 3d
accelerated view (window or screen). When I create the window at a
specific size, the OS decides to outsmart me and scale the contents inside
the window by the universal GUI scale factor even though the window itself
is the correct pixel size. We're constantly fighting this intrusion and
have awkward resizing code inside our app to deal with the OS doing
unconditional scaling. Win10 is especially nasty here, OSX at least gives
you a window creation flag to discard automatic retina (x2) scaling for
that window (and woeful are you if you do want some scaling but not x2
scaling), while Linux has other issues.
I'd be happy if there was no universal scaling factor which scales all
views. Fortunately, we dont have too many legacy apps which we need to
fix, so we can avoid the universal scale factor unconditionally applied. A
pair of BFont::GetScale() for widgets/spacing, as well as
BFont::GetFontHeight() would be sufficient for me. As long as these 2
functions are per screen/workspace.
Take care.
On Tue, 31 Aug 2021 at 09:32, Ryan Leavengood <leavengood@xxxxxxxxx> wrote:
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, andNo. It introduce serious limitation to not allow separately define UI
having most things compute UI metrics based on the font size was a
good idea.
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
