DPIPerMonitor and Text-Size scaling

Developers Ruby API
1

On Windows, if the user has set Scaling for a display (DPIPerMonitor), the html rendering AND the window size are scaled up.

However, if the user has set Text-Size scaling (in Accessibility) it changes the size of the HtmlDialog rendering but the window size is remains unchanged. So you get stuff like this:

image
image336Ă—797 53.6 KB

In both cases, if you query window.devicePixelRatio it returns > 1.0 for scaling..

For the DPI case, I dont need to change my dialog window size, for the Text-Size scaling I do..

What is the recommended way of dealing with this?

2

Can you verify that this is not happening on MacOS ?

I.e., the AI tells me that the Mac does not have a compliment to Windows system text scaling.

Yes, I filed an issue report about this recently. It is due to a change in CEF behavior.

I think it started when SketchUp upgraded to CEF version 112. But, was partly bugged as SketchUp’s CEF dialogs received only the display scaling of the primary display, so could enlarge text and elements problematically.

SketchUp 2025 upgraded CEF to version 128 and now the HTML dialogs dynamically retrieve the correct display scaling for the display they are on … or moved to.

I do not see this in my testing.

  • EDIT: (Sorry, I misread “>” as “==”)
    • ADD: Yes, if the user has set the display (that the dialog is on) to scaling above 1.0 then you will see this reflected in the window.DevicePixelRatio value.

scale_factor_dialog.rb (2.1 KB)

First of all I have system text scaling set to 1.25.

Testing on SketchUp 2025 (CEF 128.4.12)

In the first test the test dialog opened on my external (primary) UHD display which I run SketchUp on. It is set to 1.5 display scaling.

HtmlDialogScale.dialog
#=> nil
UI Scale factor : 1.5
Text Scaling    : 1.25

HTML devicePixelRatio : 1.875
devicePixelRatio / Text Scaling = 1.5

For the second test, I first dragged the dialog over to my internal (secondary) FHD display, (before closing it so it would reopen on that display,) which is set to 1.25 display scaling.

HtmlDialogScale.dialog
#=> nil
UI Scale factor : 1.5
Text Scaling    : 1.25

HTML devicePixelRatio : 1.5625
devicePixelRatio / Text Scaling = 1.25

Notice that in both cases the UI scale factor is for the primary display. Ie, it is not valid in the second test for the internal (secondary) display that SketchUp is not on, but the dialog is.

So, on MS Windows and SketchUp 2025, from within the dialog you can calculate the correct display scaling, if you pass in the system text scaling and divide the window.devicePixelRatio by it.

In other words … CEF is now multiplying the correct display scaling for the display the dialog is on, by the system text scaling when it calculates window.devicePixelRatio.

Testing in SketchUp 2024 (CEF 112.3.0)

Both displays show that same results:

HtmlDialogScale.dialog
=> nil
UI Scale factor : 1.5
Text Scaling    : 1.25

HTML devicePixelRatio : 1.875
devicePixelRatio / Text Scaling = 1.5

… which are incorrect on the secondary display because the dialog believes that display scaling is the same as the primary display monitor. It isn’t. This also leads to the incorrect calculation for display scaling because window.devicePixelRatio is incorrectly calculated (as the same as on the primary display.)

So, SketchUp 2025 is better with both CEF 128 and the updates we got for Qt 6 that fixed the multi-monitor scenarios.

3

Nice. Much as Trimble would like to kinda forget previous versions of SketchUp, us poor developers have to support them, so info like this is really helpful.

4

I found that the additional system text scaling was just too much.

I’ve been getting into the habit of defining CSS on the root document element using em baseline settings especially for text size, say either 1.0 em or 0.8 em.

Then all child element sizes, heights, widths, etc., are defined in rem (which are relative to the root value.) The JS can change the value on the root element and everything also changes accordingly.

In one of my projects (trying to remember which one) … I recreated the normal user CTRL+ | Command+ (bigger) and CTRL- | Command- (smaller) shortcuts because they were removed in CEF because some devs complained that their content was getting inadvertently zoomed.

I think I also implemented content rezoom upon window resize. Not sure, I haven’t been into that project in awhile.

5

UPDATE

I had not yet tested in SketchUp 2025, but the user zoom with CTRL & MouseWheel is working again in CEF dialogs (both Ruby & native.) The keychords are still not working but we can make them work (in Ruby dialogs) by trapping keypresses.

ADD: And even better, the native CEF dialogs like Extension Manager and 3D Warehouse remember and restore their zoom setting!

Can someone with a Mac test Command & MouseWheel to see Html dialogs zoom?

1 Like
6

I have tried it and it does nothing for my in SketchUp 2025 with html dialog boxes.

7

If I move the window to another monitor, how do I see the updated values? If I close the window and do another HtmlDialogScale.dialog, the window may or may not be on the other monitor (for reasons I can’t go in to). If it is on the other monitor, the scale values are the same, even if I have changed the other monitor to be a different DPI.

The window doesn’t have any content. It’s hard to tell if keyboard or mouse actions are changing the scale visually.

8

I was lazy with this test dialog and it only shows the initial value returned for window.devicePixelRatio via a onload callback. So, in this test, we have to rely upon it opening on whatever display it was closed on.

Somewhere I have another test dialog that detects a change, and I think (if memory serves) that it actually displays the values within the HTML content.

If you refer to UI.scale_factor then yes this will always be the same as in pre-2025 it always returned the scaling for the primary display (at least on MS Windows,) and in 2025+ it uses the new view argument, which returns the scaling factor for the display that SketchUp’s active view object is on.

This is why I said … when referring to 2025 (using CEF v128) …

… and that … at least on Windows in 2025 …

And that pre-2025 (I tested in 2024 using CEF v112) that the calculation was incorrect as CEF could only see the scaling for the primary display regardless of which display the dialog either appears on, or is moved to.

One of the release fixes for SU 2025 is that it fixed the CEF dialog display scaling awareness. And that it scales dynamically.

Takeaway is that (on Windows) going forward 2025+ the dialog JS can calculate true display scaling if the Ruby-side passes in the system text scaling.
For pre-25 the correct display scaling may need to be retrieved using Fiddle system calls and passed in along with the system text scaling.

But basically, the solution is to either adjust the content scaling by removing the extra text scaling, or allow the user to adjust it via CTRL+MouseWheel or CTRL+plus | CTRL+minus.

  • BUT, … SU 2025 CEF also allows the CTRL+MouseWheel scaling again (it was off in older versions,) yet does not accept the keychord scaling.