Animated demo becomes blurry if you resize the window and remains blurry until you move the mouse inside the window
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
People
(Reporter: mayankleoboy1, Assigned: tnikkel)
References
(Blocks 1 open bug)
Details
(Keywords: correctness)
Attachments
(3 files)
1.Open the testcase in a new tab.
2. Resize the browser window horizontally. Make sure you keep your mouse outside the browser window.
3. Notice that the triangle has become blurred. IT can even become so blurred so as to be come a faded rectangle.
4. If you will move your mouse inside the window, the triangle will get sharp again.
Try resizing the window a few times if you cant repro on the first go.
Alternately STR:
- Open the testcase in a new tab
- Move the mouse pointer on the tab-bar
- Switch to the previous tab pressing ctrl+tab
- Switch back to the testcase tab by pressing ctrl+tab
|
Reporter | |
Comment 1•3 years ago
|
||
|
||
Comment 2•3 years ago
|
||
Confirmed on Gnome Xwayland, Debian Testing, Intel.
|
Assignee | |
Comment 3•2 years ago
|
||
Looks like a ChooseScale bug.
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 4•11 months ago
|
||
FWIW, this bug is not fixed by bug 1804872
|
|
Assignee | |
Comment 5•11 months ago
|
||
When the scale of the parent transform is increasing the parent scale will be much larger than the scale of the parent transform.
The bug in the testcase happens because there are two nested transforms. The outer is animating in scale between 0 and 1. So the choosen mScale for the parent is 1 and the scale of the transform at any instantaneous point is usually smaller, say 0.2. The inner transform is just a flip and is not animated. We combine that parent transform with our local flip transform and get a transform with a scale of 0.2 and use that as our mScale. However this ignores the animating aspect of the parent transform and the fact we choose an mScale of 1 for the parent.
To fix this we bring how we use ChooseScale with webrender more into alignment with how we used ChooseScale with non-wr/FrameLayerBuilder.
The old code was structured a little differently which obscured this difference. The old code had ChooseScale (the code shared by webrender and FrameLayerBuilder) and a wrapper function ChooseScaleAndSetTransform which only FrameLayerBuilder used. The old code passed the local transform to ChooseScaleAndSetTransform, and then ChooseScaleAndSetTransform combined it with the parent scale and then passed that transform to ChooseScale. Whereas webrender passed the combined transform to ChooseScale. This would produce the same results except if the scale was animating.
This mimics how we compute the scale in HasAnimationsForCompositor branch above, where we compute a scale for the local transform and then combine that with the parent scale.
See also bug 1569215 where we first started passing the parent scale into ChooseScale so that the HasAnimationsForCompositor would choose the correct scale.
|
||
Updated•11 months ago
|
Pushed by tnikkel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/801e7b4abef9 When computing the local scale use the local transform and the parent scale rather than the local transform and parent transform. r=jrmuizel
|
||
Comment 7•11 months ago
|
||
| bugherder | ||
|
|
Reporter | |
Comment 8•11 months ago
|
||
This is fixed with the latest Nightly. Thanks!
|
|
Assignee | |
Comment 9•11 months ago
|
||
Thanks for checking. I appreciate you checking other related bugs as well.
|
||
Updated•10 months ago
|
|
||
Updated•10 months ago
|
|
||
Comment 10•8 months ago
|
||
Reproduced on an affected nightly build from 2021-06-05, on Win 10 and Ubuntu 20.04.
Verified as fixed on Firefox 116.0.3 across the following platforms: Win 10, Ubuntu 20.04, macOS 10.15 using both methods: resizing the window and switching to another tab and back.
It is also verified as fixed on Firefox 117.0 and the latest Nightly 118.0a1 on all of the above mentioned OSes.
Description
•