1538718 - Account for Display Scaling when rendering

Status: NEW

(Core :: Graphics, defect, P3)

Description

[Tom Ritter [:tjr] (OOTO Oct 18-26)]

This is a super vague bug in terms of description.

In Windows, in the Display settings, you can "Change the size of text apps, and other items." When you do so, it changes how text is rendered, as exposed to getClientRects and presumably canvas.

On a dead-simple test of a few words of text, on two different Windows 10 machines I see the height attribute change (and the bottom attribute in the same way).

• 100%
  • height: 18
• 125%
  • height: 18.3999..
• 150%
  • height: 18.66667...
• 175%
  • height: 18.6999969...

You can also set a custom scale factor

• 113%
  ** height: 18.5500003...

In addition, the right and width attributes are window-size specific, so they also change. I tested using responsive design mode, setting both computers to the same resolution (essentially letterboxing them!) of 375 x 812 and the right/width attributes were the same between them, despite different screen resolutions and window positions.

So the culprit seems to be this height difference.

Obviously there's some floating point stuff going on here with the crazy decimals. I'm not sure at this point if it can all be reduced to that given, the wide gap between .00 and .7... But perhaps.

Comment 1

[Thorin [:thorin]]

the OS system scaling or the layout.css.devPixelsPerPx value if not -1.0 is your real devicePixelRatio and it manifests everywhere. This is the subpixel problem. Zoom then also changes things but is out of scope - we expect users to be at 100% zoom and we reset that on eTLD+1 and newtabs.

One way to reduce the decimal precision is to quantize, e.g. 0.25's - but this is easily bypassed by using massive elements. Another is to randomize any decimal precision (in various domrect and other measuring methods), but this may not exactly be perf friendly (from looking at how extensions behave) - this method is detectable as a lie (but hides the precision). It is also known to cause web breakage (even though the changes are super tiny)

One method to change the result that is super performant, and breaks nothing, and doesn't create mathematical lies - is zoom. Jittering zoom per eTLD+1 (seed) by 0.2 is enough to change values (in some testing). i.e if we could randomly change 100% zoom level to actually be between 98 and 102 (so 98, 98.2, 98.4 .... 101.8, 102) that would be 20 results (doesn't help if people change their default zoom level) to help. Not sure if users would be ready for this - needs thought

Comment 2

[Thorin [:thorin]]

In Windows, in the Display settings, you can "Change the size of text apps, and other items."

separate from system scaling and layout.css.devPixelsPerPx - we also have the above which is default zoom, or zoom text only etc. On llinux we also have use large text from the OS. I see these as a separate issue that we could perhaps lock down or warn the user about. But again, randomizing somehow per eTLD seems to be our only option. I believe Brave randomizes domrect (or it may have been abandoned with the dropping of their strict FP mode), we could check with Arthur for feedback

Comment 3

[Pier Angelo Vendrame]

Rather than quantizing all the measurements, I would like to quantize the scaling.
I.e., when RFP/FPP with the right target are on, ignore custom factors such as the 113% from comment 0, and round it to 125% (with some pref like layout.css.devPixelsPerPx to let the user round it to 100% instead).

Comment 4

[Thorin [:thorin]]

That's what I implied. We control the devicePixelRatio which in turn limits any measuring to fewer buckets - in theory. But just using massive elements would bypass most of this, if not all of it.

Edit: ok, so my suggestion was to jitter zoom as a possible answer. PieroV means to control devicePixelRatio which means less buckets, agreed. Misunderstood, I thought the quantizing was elsewhere