Closed Bug 1761299 Opened 2 years ago Closed 2 years ago

Profiler markers disappear when increasing the window width


(Core :: Graphics: WebRender, defect)




100 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox98 --- unaffected
firefox99 --- unaffected
firefox100 --- fixed


(Reporter: florian, Assigned: gw)




(Keywords: regression)


(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, ie. bug 1757876.

The steps I used to reproduce: load 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.

Set release status flags based on info from the regressing bug 1757876

:gw, since you are the author of the regressor, bug 1757876, could you take a look?
For more information, please visit auto_nag documentation.

Flags: needinfo?(gwatson)

Notice the missing red and black rectangles.

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.

Both bugs happen regardless of the value of the pref gfx.webrender.compositor.

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: nobody → gwatson
Flags: needinfo?(gwatson)

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.

Pushed by
Fix raster spatial node indices being out of sync r=gfx-reviewers,nical
Has Regression Range: --- → yes
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch

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:
Attachment #9269321 - Flags: approval-mozilla-beta?

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?

Flags: needinfo?(gwatson)
Flags: needinfo?(gwatson)
Attachment #9269321 - Flags: approval-mozilla-beta?

Oh, you're right - I've cleared the uplift request. Thanks.

You need to log in before you can comment on or make changes to this bug.