Closed Bug 994546 Opened 11 years ago Closed 11 years ago

[e10s] Switching tabs sometimes doesn't repaint the window

Categories

(Core :: Graphics: Layers, defect)

29 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s + ---

People

(Reporter: mattwoodrow, Unassigned)

References

Details

Attachments

(1 file)

Attached patch Possible fixSplinter Review
This is the main blocker for bug 994088 I believe. I haven't been able to reproduce this yet. I took a guess at the issue, and wrote the attached patch. Waiting for feedback from billm to see if it works.
Attachment #8404511 - Flags: feedback?(wmccloskey)
Comment on attachment 8404511 [details] [diff] [review] Possible fix It's possible this fixes a problem, but I still see drawing issues with this patch. I'm still trying to find a consistent STR. Right now I just open a bunch of random tabs and browse around. I usually notice something wrong after 2 or 3 minutes. The only thing I've noticed so far is that it doesn't seem to happen in debug builds.
Attachment #8404511 - Flags: feedback?(wmccloskey) → feedback-
By the way, visiting about:addons and scrolling still causes problems for me when I turn on the invalidation optimizations. I doubt it's related to this problem though.
I still can't reproduce any issues with switching tabs, even with an opt build. Bill, did you notice the issue where switching tabs failed to repaint with this patch? Or just general drawing issues? We're looking to get BasicCompositor enabled by default for linux, so I suspect any normal drawing glitches will be fixed. Tab switching issues may be specific to e10s though, so need to verify that's not happening any more.
Flags: needinfo?(wmccloskey)
I did a little more investigation here. A few things: 1. This happens in both e10s and not e10s. 2. The patch in this bug doesn't have any effect. 3. Painting the entire screen always seems to fix the problem. 4. The bug is not in the computation of the invalid region: even when we incorrectly draw only a part of content, the invalid region contains either none of the content area or all of it. 5. If I convert the invalid region to a rectangle and always draw that, the problem goes away. 6. If I change the clipping code to clip to the invalid rect rather than the invalid region, then the problem remains. 7. If I change both the clipping and the CopySurface call to use the invalid rect rather than the invalid region, the problem goes away. There doesn't seem to be anything wrong with the CopySurface code though.
I had a theory that maybe the problem had to do with multiple CopySurface calls. So I turned off the invalidation optimization so we always draw the entire window. But I changed the one CopySurface call so that instead we copy to |dest| in 100x100 tiles. Then I see an effect where some of the tiles aren't drawn. It's always the later tiles--there are never gaps. Could there be some kind of race where someone reads out of |dest| before we're done drawing to it?
Flags: needinfo?(wmccloskey)
That does seem plausible, the window manager might put dest onto the screen at any point. Didn't you say you had a non-compositing window manager though? It also seems like that would cause artifacts that remain for 1/60th of a second, and the next screen refresh would pull the remainder of the changes to dest. You could try adding a call to XSync() after all the CopySurface calls.
or XFlush()
CC'ing karlt in case he has any ideas about this.
Does putting MOZ_X_SYNC=1 in the environment make a difference?
Here's a little more info. Usin XSync, XFlush, and MOZ_X_SYNC had no effect. It turns out that I am running a compositing window manager (gnome-shell). I switched to twm and the problem goes away. I also tried compiz and the problem happens there too. So it seems to happen only with compositing window managers. Finally, I noticed a really strange effect. When I draw out the frame using tiles (as in comment 6), the set of tiles that show up is not always contiguous. Sometimes some tiles in the middle are not drawn, while tiles that are drawn later show up. I'm not sure what to make of all this. One thing that's clear though is that we should be able to turn on the invalidation optimizations as long as we use a single rectangle for the invalid region. That's unfortunate, but at least we'll get some benefit.
Sounds like a window manager or driver bug. roc was having some issues with partial redraws in August 2013 that were avoided with CLUTTER_PAINT="disable-clipped-redraws:disable-culling" (for the whole session). https://bugzilla.gnome.org/show_bug.cgi?id=657071 identified a window manager bug, but perhaps https://bugzilla.redhat.com/show_bug.cgi?id=720605 indicates that this wasn't the whole problem. There seem to have been more reports with NVIDIA/nouveau drivers than others.
Thanks very much Karl. This fixes the problem. I'm using the proprietary nvidia drivers. Maybe I just need to upgrade my distro. I'm running Ubuntu from a year ago.
Given comment #13, can we close this bug as invalid and r+ the patch on bug 994088?
n?mattwoodrow re comment #13, comment #14.
Flags: needinfo?(matt.woodrow)
I'm fine closing this, since we now know what the problem is. I'd prefer to verify that a newer distribution doesn't have the problem before we land the patch in bug bug 994088. I'm sorry I've been slow about that; I'll try to do it tonight.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
This is fixed in 14.04, so I think it should be fine to land bug 994088.
Flags: needinfo?(matt.woodrow)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: