I’ve recently started using HtmlDialogs for my new extensions and was wondering if anyone knows this.
I usually develop on Windows 7 with no high DPI scaling. The pixel measurements I set for the dialog in Ruby and the pixel dimensions in my CSS maps 1:1 to screen pixels.
I have just tested my plugin on my friend’s computer in Win 8 with 125% scaling. My CSS dimensions still map 1:1 to screen pixels, but the dialog itself is sized up by factor 1,25 in each direction, making the layout somewhat wonky.
I was under the impression that both the dialog and its content should be scaled up by the same factor. Does anyone know if this is just a Win 8 oddity, or if it applies to Win 10 and Mac as well?
A few years ago I jumped into the DPI/PPI mess, but it’s a bit foggy. Back then, standards were somewhat loose.
By chance, do you have any dialogs set up using em / rem units for CSS? Be interesting to know how various OS’s compare with that. The whole DPI/PPI issue is the reason many sites try to use nothing but em / rem and svg…
Also, I don’t know, does MacOS have an equivalent to Windows DPI setting? I would assume so for accessibility, but maybe not. And, finally, how does SU behave (across OS’s) when DPI settings are changed? If it doesn’t match standard OS apps, should dialog behavior follow SU, or the OS?
Sorry. Messy topic. Certainly something that would be helpful to know more info about, especially for plugin devs who can’t check both OS’s…
I usually use pixel as units as I’m used to it and know about how much, e.g., 100 pixels are. On the Ruby side you also use pixels to set dialog diemnsions, and I think it makes sense to stick to the same unit for layout (unless you use vh and vw). However, when the DPI scaling is other than 1 these “pixels” should be logical pixels, not physical ones. In SU2017 on Win 8 both kinds of pixel measurements seem to be mixed.
I use SVG quite a lot for graphics but then don’t really care what units I use inside of the SVG file, as I typically scale the whole image to fit a certain container. If the image is 100px wide with 1px wide lines, or 100 mm wide with 1 mm wide lines make no real difference in these cases.
I think Mac was first with high DPI scaling, at least on computers, to make Retina displays usable. Could have got that wrong though.
At one time @thomthom answered me on this subject expounding upon the treasures and pitfalls (bugs) etc of using these methods in various scenarios. But I cannot find it. It was likely private communication.
This would be a very good subject for a “primer” file for the API Doc “Files” collection.
Add, that the API Release Notes have no help regarding any bugs or shortcomings or even fixes in this area.
Be careful with “old” assumptions. Consider the fairly-common 4K displays now, some 5K (such as the iMac I’m typing this on), and Dell’s 8K monitor products. During the 80s and 90s when most monitors were between say 72 DPI and 100 DPI the negative consequences of making pixel-based assumptions were minimal. Today, they are more significant with 200 to 300 DPI monitors.
That is what DPI scaling is for. The px measurements defined in CSS are i logical pixels, not physical pixels. Em is no safer as it just maps to a specific number of logical pixels (I think 16 is the default value). vh and vw are good for overall layout but can’t be used for text, buttons or other elements as it would make them inconsistent between windows.100 logical pixels on my screen should be about the same as 100 logical pixels on your screen, adjusted to personal preferences in UI sizing. I see no problems in using pixel values.
I’m not 100% sure but I think a cm in CSS (on screen) maps to 96 logical pixels, and thus a mm to 9,6 px. The pixel scale ratio (physical to logical) is usually some rather even number like 1, 2, 0,5, 1,25 etc to minimize Moiré artifacts and blurriness, and not exact values based on physical screen resolution. This would mean mm and px values are equally safe to use on screens, as the factor in between is always constant. In print a CSS mm should map to a physical mm on the paper but though.
I was remembering slightly wrong, a CSS screen inch, not cm, maps to 96 logical pixels. In theory the logical px should be defined as a 96th of an inch, but for sharpness on screens it is rounded to a somewhat even number of physical pixels. A CSS inch, mm, cm, pica or other absolute unit therefore doesn’t exactly map to the physical unit by the same name, which can be quite confusing. Also the pixel scale ration can be changed by the user, typically enlarged by elderly and visually impaired, meaning absolute units in CSS differ even more from the real world physical unit.
In the end I personally think logical pixels are the easiest to work with, as I have a lot of experience in how it looks on the screen, and is the only available unit to define the HtmlDialog size. Also W3C reccomends it for screen use:
Here are mine. Same results as yours. SU2018 does something about DPI scaling, whereas SU2017 does not (which is ennoying for SU2017 Make users, since there will be no update to this version).
Note that for SU2018, the dialog box has a very small scrolling
It seems like the absolute units (inches and cm) are proportional to logical pixels in all cases, regardless of the actual size of the logical pixels. Also it seems like SU 2018 applies the scale factor value to both dialog dimensions and CSS logical pixels, whereas SU2017 only applies it to the dialog frame, not the content.
The only thing I’m confused by is @john_drivenupthewall’s first dialog. How did you do to resize it? I expected it to look as it does in the second image from the start.
Hey, SketchUp 2017 scaled the HtmlDialog content too! Odd it didn’t for anyone else. Maybe the scale inside HtmlDialogs factor is rounded to whole integers on SU2017, causing 1,25 to result in 1.
