GNOME Bugzilla – Bug 706156
Windows that update in another workspace cause the entire screen to be redrawn
Last modified: 2021-07-05 14:21:29 UTC
I've been playing with COGL_DEBUG=rectangles. Do this: 1. export COGL_DEBUG=rectangles 2. gnome-shell --replace 3. Open a second workspace 4. In that second workspace, run glxgears (i.e. something that continuously updates its window). 5. Switch to the first workspace, which should be mostly empty and quiet. 6. Watch the flickering rectangles, which indicate that everything is being repainted. Gnome-shell should not need to repaint everything if a window outside the current workspace updates itself. For contrast, switch to the workspace where the glxgears window is. You'll see that only its window's client area is updated, as expected. I don't know why going away from the current workspace would make a difference.
Also happens for non-GL windows, e.g. "xclock -update 1".
We do queue a redraw in response to damage events. We should and can optimize that out in such cases (also for obscured windows). I do have patches in the works that do exactly that see: https://bugzilla.gnome.org/show_bug.cgi?id=703332 Still need to fix them up, planning to do that in the coming days.
Thanks, this is good news. I'm rather ignorant of how frame synchronization works or how the whole compositing pipeline works, so please bear with me. Does throttling offscreen windows to 100ms mean that "the whole screen will only repaint every 100ms" for those busy offscreen windows? This would be a bit unfortunate for remote displays like VNC (we have plans to make VNC and similar be smart about not sending data on the wire for screen areas that didn't actually change, but in the meantime...). ... or is it possible to get the windows' frame counters synchronized, without actually dealing with their damage data?
(In reply to comment #3) > Thanks, this is good news. > > I'm rather ignorant of how frame synchronization works or how the whole > compositing pipeline works, so please bear with me. > > Does throttling offscreen windows to 100ms mean that "the whole screen will > only repaint every 100ms" for those busy offscreen windows? No. It means that they will get the FRAME_DRAWN / FRAME_TIMINGS messages every 100ms. That means that the windows will redraw their contents (offscreen) at that interval but as long as they are obscured nothing changes on the screen.
Excellent - this is reassuring, thanks :)
Lets mark this as a dupe ... there is no reason to have two bugs for the same thing. *** This bug has been marked as a duplicate of bug 703332 ***
I would still like some investigation into why we're queueing redraws for unmapped actors. The Clutter code should fizzle out redraws for unmapped actors, and actors on other workspaces should be hidden. It does check that we have no active clones, so perhaps we're leaking clones in alt-tab / overview / workspace animation switch? That's a much more serious problem.
(In reply to comment #7) > I would still like some investigation into why we're queueing redraws for > unmapped actors. The Clutter code should fizzle out redraws for unmapped > actors, and actors on other workspaces should be hidden. > > It does check that we have no active clones, so perhaps we're leaking clones in > alt-tab / overview / workspace animation switch? That's a much more serious > problem. Running with CLUTTER_DEBUG=paint should tell you what's going on.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.