Rounding issue fixup
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox134 | --- | fixed |
People
(Reporter: fkilic, Assigned: fkilic)
References
Details
Attachments
(3 files)
Fixup of https://bugzilla.mozilla.org/show_bug.cgi?id=1873382#c23. it looks like mAppUnitsPerDevPixel uses int instead of float and that causes different dPR between RFP and non-RFP.
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 5•29 days ago
|
||
FWIW ... very close on my device with a real DPR of 1
(I'll check other real various DPRs at some stage)
in the examples
90%
=1.81818
(spoofed)110%
=2.22222
(spoofed)
modify toolkit.zoomManager.zoomValues
and add 1.8
and 2.2
zoom levels, test without RFP
MediaQueryList { media: "(resolution: 1.71429dppx)", matches: true, onchange: null }
MediaQueryList { media: "(resolution: 1.81818dppx)", matches: true, onchange: null }
MediaQueryList { media: "(resolution: 2dppx)", matches: true, onchange: null }
MediaQueryList { media: "(resolution: 2.22222dppx)", matches: true, onchange: null }
the values are the same, so IDK what gives :)
Assignee | ||
Comment 6•27 days ago
•
|
||
I'm not sure what you mean (literally, my English fails me very often). Are you saying it is still not 100% correct? or are you verifying that it works?
I get the following values on a naturally 2 DPR device
non-RFP
- 30%: 0.6
- 50%: 1
- 67%: 1.3333333333333333
- 80%: 1.5789473684210527
- 90%: 1.8181818181818181
- 100%: 2
RFP: - 30%: 0.6
- 50%: 1
- 67%: 1.3333333333333333
- 80%: 1.5789473684210527
- 90%: 1.8181818181818181
- 100%: 2
With layout.css.devPixelsPerPx
set to 1, I get
non-RFP:
- 30%: 0.3
- 50%: 0.5
- 67%: 0.6666666666666666
- 80%: 0.8
- 90%: 0.8955223880597015
- 100%: 2
RFP: - 30%: 0.6
- 50%: 1
- 67%: 1.3333333333333333
- 80%: 1.5789473684210527
- 90%: 1.8181818181818181
- 100%: 2
The numbers I get seem to match with spoofed and naturally 2 dPR. I used window.devicePixelRatio though, is it somehow different for media queries?
Comment 7•27 days ago
|
||
edit: noticed something, will post image soon
We're comparing values per test, not across two different configs, although that helps and is something I plan to do - i.e that we're consistent across each dpr value regardless of how it was achieved
What I did was on the resize event of TZP (locally, not live) I added a console log for window.matchMedia('(resolution: ' + window.devicePixelRatio + 'dppx)')
and then just caught everything in the console as I zoomed from 30 to 500. The image shows at least two that do not match, and this is device with DPR == integer (so we would expect subpixel entropy to not occur, so to speak)
Something is going on - but IDK what. There's also -moz-device-pixel-ratio, -webkit-min-device-pixel-ratio (which rounds down to 0.25, 0.5, 1, 2 or 4 ), dpcm and dpi.
Comment 8•27 days ago
|
||
false alarm
device is DPR 1, RFP is off ... zoom level 110% (nightly) and there's a diff
1.0909091406250007
(dppx) vs1.0909090909090908
(dpr)- but that's because I'm using a binary search between
resolution
andmax-resolution
to return the min value
Assignee | ||
Comment 9•27 days ago
|
||
hmm it is still interesting that media query doesn't always match. I'm also not sure. I suspect float conversions but I'm also not sure how to solve it.
Comment 10•27 days ago
|
||
continuing over at https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43239
Description
•