Profiler markers disappear when increasing the window width
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr91 | --- | unaffected |
| firefox98 | --- | unaffected |
| firefox99 | --- | unaffected |
| firefox100 | --- | fixed |
People
(Reporter: florian, Assigned: gw)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
I only tried to reproduce this on Mac. I can only reproduce on my external 27" screen. I can't reproduce the bug at these resolutions: 3840x2160, 1920x1060. I can reproduce at these resolutions: 2560x1440, 3008x1692, 3360x1890.
It seems to me the bug happens when the scaling factor isn't an integer.
I can mozregression, which gave https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e981d54aa148bd2d73f0f8f8ac4e90b13420a77f&tochange=3c3520362bda55a31840d9a4ed3a6cc9bb097cfd, ie. bug 1757876.
The steps I used to reproduce: load https://profiler.firefox.com/public/3c9tta4gkh0k5nr0jkhcg0mza7vfh38yree4rtg/ and maximize the window. See that some markers disappear when the window is large. For some reason, the markers of the selected track still appear.
Comment 1•4 years ago
|
||
Set release status flags based on info from the regressing bug 1757876
Comment 2•4 years ago
|
||
:gw, since you are the author of the regressor, bug 1757876, could you take a look?
For more information, please visit auto_nag documentation.
| Reporter | ||
Comment 3•4 years ago
|
||
Notice the missing red and black rectangles.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
I can reproduce this. And after using my browser at this wide width for a while, I even noticed another bug that only happens with >= 4096 dev pixel window widths, this time involving video!
On YouTube, in "Theater mode" (so that the video controls span the entire width of the page), while a video is playing, hovering the video makes the video controls appear with a delay. There's a shadow at the bottom of the video that appears instantly, but the controls on top of the shadow appear later. With a narrow window, both the shadow and the controls appear at the same time, with an animation.
Comment 5•4 years ago
|
||
Both bugs happen regardless of the value of the pref gfx.webrender.compositor.
| Assignee | ||
Comment 6•4 years ago
|
||
It doesn't occur in a default build for me, but I can reproduce it immediately if I change the value of MAX_SURFACE_SIZE to be 2048 or 1024, so it does seem related to that.
| Assignee | ||
Comment 7•4 years ago
|
||
When the max surface size is exceeded, the raster spatial node
for a given surface is adjusted in get_surface_rects. However
a locally cached variable of the old raster spatial node index
was being used as a parameter when creating the render task.
Instead, only retrieve the raster spatial node after the call to
get_surface_rects, ensuring that it gets the updated value.
Updated•4 years ago
|
Comment 9•4 years ago
|
||
| bugherder | ||
| Assignee | ||
Comment 10•4 years ago
|
||
Comment on attachment 9269321 [details]
Bug 1761299 - Fix raster spatial node indices being out of sync
Beta/Release Uplift Approval Request
- User impact if declined: Visual glitches on some pages, mostly when zooming
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The patch is a simple fix for a clear bug. If it doesn't graft cleanly, I can manually rebase it, but it's quite small.
- String changes made/needed:
Comment 11•4 years ago
|
||
Glenn, the regressor (bug 1757876) landed in 100 and the fix in this bug also landed in 100. Why is an uplift needed to 99?
| Assignee | ||
Updated•4 years ago
|
| Assignee | ||
Comment 12•4 years ago
|
||
Oh, you're right - I've cleared the uplift request. Thanks.
Description
•