Heavily blurred text on ImpressJS while rotating
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
People
(Reporter: mayankleoboy1, Assigned: tnikkel)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(2 files)
enable WR
Go to https://impress.js.org/#/tiny
Press enter/rspace bar
The text will rotate, position, scale
ER: sharp text, like without WR
AR: heavily blurred text
please see the video
|
Reporter | |
Comment 1•4 years ago
|
||
|
|
Reporter | |
Comment 2•4 years ago
|
||
Also, 2 other text distortions :
- At the ~4 second mark, when the "impress.js" fades away, the text bounces up and down
- Whenever any text fades out, it becomes blurry
|
Assignee | |
Comment 3•4 years ago
|
||
I focused on one specific glitch, when the word "rotating" rotates, and found the regression range:
-> bug 1569215
It's possible the other glitches shown in the video could be different or have a different regression range, but I'll look into that glitch first and hopefully it fixes all the problems here, but we'll see.
|
|
Assignee | |
Comment 4•4 years ago
|
||
Looks like there is a 1/6 scale transform, a flip and scale transform that is ever so slightly 3d (seems like it's a rounding error away from being 2d), and then a 6 scale transform that also undoes the flip, and then finally the transform on the rotating text.
ChooseScale determines that 1.0 is the right (local) scale to use for the rotating text based on it's local transform (just a rotation), and then it multiplies it by the passed in scale, which is the scale from the parent stacking context helper, which is 0.16666 (the 1/6 scale). So we use a scale of 0.1666 for this stacking context when it should be 1.
|
|
Assignee | |
Comment 5•4 years ago
|
||
I think the "cause" of this bug is bug 1449640. The 6 scale transform gets ignored because the parent is preserve3d, so we keep passing down the 1/6 scale.
Bug 1449640 added the preserve3d check because it matched the behaviour of ChooseScaleAndSetTransform (this was when webrender didn't use ChooseScaleAndSetTransform). Except it looks at the preserve3d for the current item, webrender looks at preserve3d on the parent stacking context helper.
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 6•4 years ago
|
||
Back when webrender did not call FrameLayerBuilder::ChooseScale (it was called ChooseScaleAndSetTransform back then until it was factored out in bug 1415987) bug 1449640 landed which made the webrender scale choosing more closely align with FrameLayerBuilder::ChooseScale by not computing a scale of there was preserve3d or perspective involved. That patch had a bug, it looked at the parent stacking context helper to see if it had preserve 3d, but FrameLayerBuilder::ChooseScale looks at the current "stacking context".
This didn't cause a problem in the testcase from this bug until bug 1569215 landed. In the testcase in this bug we have a stacking context with a 2d transform whose parent stacking context is preserve3d. So we pass down the scale from the parent stacking context and completely ignore the scale induced by the 2d transform. Passing 1.f to ChooseScale instead of the parent scale factor "undid" this mistake, so when that was fixed we regressed this testcase.
I'll make a test for this.
|
||
Updated•4 years ago
|
Pushed by tnikkel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c030dc560ffe When computing the scale for a stacking context with webrender look at this stacking context to see if it is preserve 3d and not it's parent to match FrameLayerBuilder::ChooseScale. r=jrmuizel
|
||
Comment 8•4 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 10•4 years ago
|
||
Excellent! Thank you.
|
||
Updated•4 years ago
|
Description
•