Glyphs are clipped at various zooms and scales
Categories
(Core :: Graphics: WebRender, defect, P2)
Tracking
()
People
(Reporter: Fanolian+BMO, Assigned: aosmond)
References
(Blocks 1 open bug, Regression, )
Details
(Keywords: regression, reproducible, Whiteboard: [sci-exclude])
Attachments
(8 files, 1 obsolete file)
814.38 KB,
video/mp4
|
Details | |
18.67 KB,
text/plain
|
Details | |
38.55 KB,
image/png
|
Details | |
91.24 KB,
image/png
|
Details | |
364.17 KB,
text/html
|
Details | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Build ID: 20190529095015
Steps to reproduce
- Create an event in Google Calendar. (Day/Week/Month view, it does not matter.)
- Modify the browser width so as to change Calendar's flexbox size.
- Observe the text of the event title.
Actual result
(Please refer to the attached screencast.)
At some widths the text clipping is more obvious than others.
Expected result
No text clippings.
Additional Notes
There is no text clippings if I disable WebRender.
Updated•5 years ago
|
about:support is attached.
Some desktop info
OS: Win10 1809 17763.529
VGA: Nvidia GeForce GTX 760
VGA driver: 430.64
Comment 2•5 years ago
|
||
What's your device pixel ratio? You can see your ratio here: https://www.mydevice.io/
Comment 3•5 years ago
|
||
Win10, GTX1060, Dell U2515H
Screen metrics
Size
JS screen.width: 2560px
JS screen.height: 1440px
@media (device-width): 1920px+
@media (device-height): 1366px+
Pixel ratio
CSS pixel-ratio: 1
JS pixel-ratio: 1.0000
Density
Resolution (dpi): 96.00dpi
Resolution (dppx): 1.00dppx
Resolution (dpcm): 37.80dpcm
Misc
Root font size: 16px
Orientation: landscape
Device Aspect-Ratio: 1.78
Updated•5 years ago
|
(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)
What's your device pixel ratio? You can see your ratio here: https://www.mydevice.io/
Screen metrics
Size
JS screen.width : 1920px
JS screen.height : 1080px
@media (device-width): 1920px+
@media (device-height): 1080px+
Pixel ratio
CSS pixel-ratio: 1
JS pixel-ratio : 1.0000
Density
Resolution (dpi) : 96.00dpi
Resolution (dppx) : 1.00dppx
Resolution (dpcm) : 37.80dpcm
Misc
Root font size : 16px
Orientation: landscape
Device Aspect-Ratio : 1.78
Comment 5•5 years ago
|
||
I have reached this issue due to it's "regression-window-wanted" tag. Considering the fact that I don't really understand what the problem is here, I will try to request this information from the reporter, along with an explanation on how to do it.
Fanolian, Can you please try and regress this issue you reported? You can do that with an application created by mozilliens to determine which exact build introduced it. This app is mozregression; You can download it from here:
https://github.com/mozilla/mozregression/releases/download/gui-0.9.39/mozregression-gui.exe
(You also need python 2.7.15 (or 2.7.x) for it to work: https://www.python.org/ftp/python/2.7.15/python-2.7.15.amd64.msi)
Steps:
- You have to determine a build that does not reproduce the issue.
Considering that the 3 main version of the browser, firefox69, firefox68, firefox67 reproduces this issue, then you should probably look back to older versions and try to find one that does NOT reproduce it:
a. Open mozregression-gui.exe
b. Click "File" -> "Run a single build"
c. On "Basic configuration" screen, select Build Type: "opt" and click "Next" button.
d. Skip "Profile selection" screen by the "Next" button.
e. In the "Single run wizard" screen, "Build from:" section, select "release" instead if "date" and then select a release number under 67.
f. The mozregression app will open the selected build. Try to reproduce the issue and remember the release chosen.
g. Repeat steps b. to e. until you find a build that does not reproduce the issue; Remember it.
h. If even builds older than release 20 reproduce the issue, than you can consider this issue as not a regression and stop the investigation. - You will use mozregression app to "bisect" builds that reproduce the issue by builds that do not reproduce it in search of the one build/changeset that introduced the issue, in the first place:
a. Open mozregression-gui.exe
b. Click "File" -> "Run a new bisection"
c. On "Basic configuration" screen, select Build Type: "opt" and click "Next" button.
d. Skip "Profile selection" screen by the "Next" button.
e. On the Bisection wizard screen, you will need to select a build that reproduces the issue and one that does not:
e1. In the "Last known good build:" section, select "release" on the right drop-down and the release number that you found that does NOT reproduce the issue.
e2. In the "First known bad build:" section, select "release un the right drop-down and a release number that you know to reproduce the issue, which are 68 or 67 or any other buiulds that you tested before and found to reproduce it (the earlier the build chose, the faster it will be to run the bisection).
f. Click "Finish" to start the bisection process.
g. builds will open one-by-one, you will need to test each one of them and see whether the issue reproduces. If it reproduces, then you need to select the "bad" button in the mozregression window and if not, you need to select the "good" button.
h. When bisection is done, you will have the information in the "Log View" section of the mozregression window; bisection may also fail due to not enough builds, but the logs can always be usefull. - Copy the logs in a text file and attach it to this bug.
If there is still information you need regarding the regression process, please request information from me.
Alternatively, please explain exactly what this issue is and what is a situation where it would not reproduce and I will try to regress it myself.
Thank you for your contribution!
Sorry for the delay. I forgot about this bug.
Last good Nightly: 2018-09-19
First bad Nightly: 2018-09-20
pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9812141ec78239560283181ce610249d181b74b6&tochange=5347c7e4811a1a4d80bcee4119cead9192fdff69
Further bisection:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a1a0f861a0ae43b0a5668aa292e4705885ff19be&tochange=14c6b338e32c1da04218311b26e14cd2b9a3102b
This is regressed by bug 1492566.
Note:
This regression is about the clipping on the left (the left S) only.
There should be another clipping bug on the right but it is not introduced by bug 1492566. I need more time to investigate.
@jrmuizel, at 0:32 in the video in comment 0, the black box is overlapping the vertical grey line. Is it another bug? Thanks.
(I am marking Firefox67 as wontfix since this is a regression from 64.)
There should be another clipping bug on the right but it is not introduced by bug 1492566. I need more time to investigate.
Actually, to my layman's eye I do not think it counts as a clipping. Also I checked with WebRender disabled and it exhibits the same behaviour.
Updated•5 years ago
|
Comment 8•5 years ago
|
||
Andrew, do you want to take a look at this, see if you can reproduce, and perhaps make a reduced test case?
Updated•5 years ago
|
Assignee | ||
Comment 9•5 years ago
|
||
Bug 1574493 changed how clips got snapped quite a bit, before it was somewhat unpredictable how they would interact with an element. They should be consistent relative to each other now. I have been unable to reproduce thus far. Could you retry on current nightly? If you can still reproduce, can you confirm what font is selected? (Shift right click on the calendar entry, select inspect element, and hit the Fonts tab on the right hand side.) That may be important for reproducing. Thanks!
Reporter | ||
Comment 10•5 years ago
|
||
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
20191007092954
I can still reproduce it on current Nightly. The font is the default web font Roboto Medium.
Assignee | ||
Comment 11•5 years ago
|
||
Thanks, I get the same font selected which is good :). I believe I have been able to reproduce after trying different zoom factors.
Assignee | ||
Comment 12•5 years ago
|
||
It isn't quite as severe, the S on the left is fine, and the S on the right is clipped too much.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 13•5 years ago
|
||
I think I see the fix for this, at least to the extent I suffer from the problem. Build incoming for reporter to try out.
Assignee | ||
Comment 14•5 years ago
|
||
If this indeed is the fix, it won't be upliftable to 70 due to depending on bug 1574493. That would have fixed the problem if I did not make another mistake in using the incorrect origin point for the glyph offset calculations :). Hopefully this is the remaining root cause of the reported issue. I'll needinfo once the build is available.
try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7eefcc82e9504a8c10c41d43050ee75c7569c5ed
Assignee | ||
Comment 15•5 years ago
|
||
Assignee | ||
Comment 16•5 years ago
|
||
Trimmed down a Google calendar page. This reproduces for me at 67% zoom (with my desktop at 200% scaling).
Assignee | ||
Comment 17•5 years ago
|
||
So my patch fixes it, but it breaks a ton of reftests as it changes the text positioning too much. Not snapping the text items doesn't work because it is a rounded clip in the clip chain that appears to be causing the problem, and it is a bit difficult to not snap all clips in the clip chain.
Assignee | ||
Comment 18•5 years ago
|
||
At this point there are a few things that are interesting:
-
We round the rect dimensions for rounded rect clips in display list building. This is wrong and will impede any fixes moving forward. This should be removed and any reftest failures investigated separately.
-
We snap text primitives in scene building just like any other. We should probably not do this. The rect and clip rect are very special, and the snapping doesn't actually change the glyph positioning at present. This may also impede a true fix like #2 and should be removed.
-
WebRender and non-WebRender appear to use different glyph spacing from each other. Comparing zoomed in rendering of the reduced test case shows that the S is actually translated one pixel to the left with WebRender. It seems plausible that this different positioning is not taken into account during layout when the rounded rect clip is generated in the item's clip chain, and as a result, it ends up being too tight and clips part of the S.
Updated•5 years ago
|
Assignee | ||
Comment 19•5 years ago
|
||
It turns out that item 3 in comment 18 is probably caused by several issues in the shader. Maybe I don't need the extra bug filed. This also seems to fix bug 1575258 as an additional bonus. The following try includes the shader fixes, as well as items 1 and 2.
try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=bfd0fdc9d7fd528791cd866bdef23bf8339b2ad2
Assignee | ||
Comment 22•5 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #21)
Is this fixed by your text snapping changes?
No. I had hopes but it did not.
Assignee | ||
Comment 23•5 years ago
|
||
This is happening on slack at 100% zoom and DPS of 1. Safe to assume this may be more widespread than initially thought. Currently the original reduced test case only reproduces at non-100% zoom and DPS of 1 for me. Bumping up priority to indicate I'm investigating.
Assignee | ||
Comment 24•5 years ago
|
||
Note that turning off overflow: hidden resolves the problems in both cases (which I did not note previously for the calendar), so this may not just be a case that our clips were snapped incorrectly relative to the content.
Reporter | ||
Comment 25•5 years ago
|
||
For the reduced test case and on Calendar site on my computer, the clipped left edge on the left S is fixed by bug 1575258, even with overflow:hidden
enabled.
Assignee | ||
Comment 26•5 years ago
|
||
(In reply to Fanolian from comment #25)
For the reduced test case and on Calendar site on my computer, the clipped left edge on the left S is fixed by bug 1575258, even with
overflow:hidden
enabled.
And at different zooms? It breaks for me at 30% and 67% for example.
Assignee | ||
Comment 28•5 years ago
|
||
(In reply to Fanolian from comment #27)
They are fixed too.
Huh, that is very surprising. Thanks for following up. You already confirmed the font is Roboto Medium (same as me). I'm at least glad my other changes helped some configurations :). Hopefully the problem is merely moved around rather than more widespread.
Assignee | ||
Comment 29•5 years ago
|
||
This patch solves the Google Calendar and Slack text cut offs for me. Every failure in the push is an unexpected pass :D. Will go up for review once I write a wrench test case.
Assignee | ||
Comment 30•5 years ago
|
||
try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6ada69ce154f06241db329d0ef5c9ece15adb167
Rebased and fixed annotations (except maybe Android).
Assignee | ||
Comment 31•5 years ago
|
||
Snapping glyph positions are an internal detail to a primitive. As such,
any snapping required must be taken into account when calculating the
local rect. That ensures that when the clip is applied, it doesn't cut
off parts of the glyph that would have been retained after snapping.
Assignee | ||
Comment 32•5 years ago
|
||
try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c54374ea25284111416acae57aa5de8b9ed153fb
Incorporates the fix for bug 1600237. Hopefully will be all green.
Assignee | ||
Comment 33•5 years ago
|
||
I may rewrite that test as a wrench test actually. It would make more sense probably...
Assignee | ||
Comment 34•5 years ago
|
||
This probably won't land before the soft freeze, but I would likely want to uplift very early in the beta cycle.
Comment 35•5 years ago
|
||
Pushed by aosmond@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b5cfc7ed22b4 Snap glyphs before clipping in the shader. r=lsalzman
Assignee | ||
Comment 36•5 years ago
|
||
Comment 37•5 years ago
|
||
Pushed by aosmond@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5ad40d4bd5a3 Followup to mark more tests as passing.
Assignee | ||
Comment 38•5 years ago
|
||
Comment 39•5 years ago
|
||
Pushed by aosmond@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/11e31e9d1c07 Followup to mark more tests as passing (again).
Comment 40•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b5cfc7ed22b4
https://hg.mozilla.org/mozilla-central/rev/5ad40d4bd5a3
https://hg.mozilla.org/mozilla-central/rev/11e31e9d1c07
Updated•5 years ago
|
Updated•5 years ago
|
Comment 43•5 years ago
|
||
Can you help further and attempt to verify the fix that was pushed to Nightly?
Reporter | ||
Comment 44•5 years ago
|
||
(In reply to Bodea Daniel [:danibodea] from comment #43)
Can you help further and attempt to verify the fix that was pushed to Nightly?
It is fixed for me. Tested on 20191209215019. Thank you very much.
(For future reference: do remember turning off overflow: hidden
when testing, especially when the text is small.)
Updated•3 years ago
|
Description
•