Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Redraws do not always render completely - affects all hardware - workaround: CLUTTER_PAINT=disable-clipped-redraws:disable-culling|
|Product:||[Fedora] Fedora||Reporter:||Zdenek Kabelac <zkabelac>|
|Component:||mutter||Assignee:||Peter Robinson <pbrobinson>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||adel.gadllah, ajax, atomic.quark, awilliam, bugs.michael, bugs.sdavis, dan.krejsa, david, dkbatson, ebassi, georgopl, hdegoede, itamar, jeff, kmaraas, madko, mads, mail, maxamillion, mcepl, metherid, m, otaylor, Paul, pbrobinson, pedrogfrancisco, samuel-rhbugs, sheltren, tflink, tiagomatos, travneff, walters, xgl-maint, yaneti|
|Fixed In Version:||mutter-184.108.40.206-1.fc16||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-09-19 19:52:16 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||713565, 713568|
Description Zdenek Kabelac 2011-07-12 05:01:31 EDT
Created attachment 512371 [details] mc scroll artefact in gnome-terminal Description of problem: Ok, this bugzilla might not be the best - but here are the symptoms I'm experiencing with recent Fedora Rawhide and it's Gnome/X-build. The problem is with screen refresh - it looks like occasionally now Xorg doesn't refresh properly some window area. I've used: xorg-x11-server-220.127.116.11-8.20110510.fc16 where even my text editor (xfte) which is pure Xlib based was giving me very strange refresh results- thus I've downgraded to: xorg-x11-server-18.104.22.168-6.20110510.fc16 - this seems to help to my xfte - but still other application (mainly gnome/gtk oriented) seems to have weird artefacts (using gnome-shell environment). I'm attaching result of 'mc' running in gnome-terminal - where I'm using wheel mouse button to scroll text window in mc viewer up and down and withing few seconds this strange scroll result happens. I'd have though it could be just the bug of gnome-terminal - but I'm seeing similar things also with i.e. firefox or thunderbird (thought not so easily trigerable) I should also note - when I move mouse outside of 'gnome-terminal' window - in that moment the window is properly refreshed and screen of 'mc' application looks correct. Also I'm not sure if it's related - but also my 'pidgin' window seems to be missing proper screen refresh - i.e. it's like several second delay before the windows is updated and just entered message appears in the window. I'm starting to see this behaviour approximately from the 5.Jul.2011 - but so far I've not found a single package which revert would fix all the problems. Revert xorg-x11-server fixed 'some of them' - but definitely not all. Currently I'm confused where this bug should be moved ? (Xorg/gnome-shell/gtk? maybe combination of all of them?) Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-22.214.171.124-6.20110510.fc16.x86_64 gnome-terminal-3.0.1-1.fc16.x86_64 gtk2-2.24.5-1.fc16.x86_64 gtk3-3.1.8-1.fc16.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Comment 1 Zdenek Kabelac 2011-07-12 05:02:52 EDT
Created attachment 512372 [details] xorg.conf (unmodified for quite some time)
Comment 3 Matěj Cepl 2011-07-12 15:35:28 EDT
(In reply to comment #1) > Created attachment 512372 [details] > xorg.conf (unmodified for quite some time) Please add drm.debug=0x04 to the kernel command line, remove /etc/X11/xorg.conf (or move it away), restart computer, and attach * fresh X server log file (/var/log/Xorg.*.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Comment 4 Zdenek Kabelac 2011-07-13 04:35:32 EDT
Opps forget to mention - I'm using kernel 2.6.39 dated from 20 May (as 3.0 kernels have various stability issues on suspend/resume and USB). Thus there shouldn't be any problem related to kernel - as kernel has not changed in my case for nearly 2 months. The problem has to be related with some user space code - and it happened most probably between 1st Jul. - 7th Jul. (however as I'm not rebooting with each yum upgrade - it's not so easy to guess which package it was - and 'yum downgrade' is still quite far away from usability for this case. When I'll make some reboot - I'll check for drm.debug - though I think for this bz it's not related.
Comment 5 Matěj Cepl 2011-07-13 07:39:52 EDT
(In reply to comment #4) > The problem has to be related with some user space code - and it happened most > probably between 1st Jul. - 7th Jul. (however as I'm not rebooting with each > yum upgrade - it's not so easy to guess which package it was - and 'yum > downgrade' is still quite far away from usability for this case. yum history may help?
Comment 6 Zdenek Kabelac 2011-07-14 05:51:07 EDT
So I've made couple more experiments here - and noticed very trivial reproducer just using 'less' in 'xterm' - where it often left half of screen empty and refresh needs to be induced by i.e. window move. Then I've checked the same with just plain 'twm' desktop - and the problem was gone. So the bug is gnome-shell/mutter related - unfortunately it's quite hard to figure out the set of packages which would bring back usable desktop - I've tried to downgrade some set of packages - but have not figure mutter3.0 version - unless I'd downgrade mostly all gnome packages. So I'm moving this bug to mutter package - as this one is mostly responsible for refresh. Mutter 3.0 seems to be working ok - though I've not been able to get usable combination with gnome-shell in current rawhide (to many related deps would need to be satisfied) Mutter 3.1 & gnome-shell has serious refresh problem (looks like some events are lost).
Comment 7 Peter Robinson 2011-07-14 13:49:09 EDT
This isn't mutter related and a simple test in xterm when using mutter vs twm isn't an appropriate test to prove its mutter as mutter uses the 3D X drivers and twm uses 2D drivers. Its likely a mesa/intel driver issue
Comment 8 Zdenek Kabelac 2011-07-15 05:24:58 EDT
I've tried also to downgrade to June's version of mesa libraries - with no luck. I could try probably earlier version as well - but so far I'm more convinced the problem is related with mutter 3.1 version. I.e. - with plain mutter and no other package change - 3.0 works - while 3.1 is showing problems (thought I admit package deps are a bit of problem here)
Comment 9 Zdenek Kabelac 2011-07-15 05:50:26 EDT
To be a bit more specific with versions here: When I take current updated rawhide (2011-07-15 11:44 CEST) and just downgrade these packages: (removing --nodeps cogl package) clutter-1.6.16-3.fc16.x86_64.rpm mutter-3.0.1-3.fc16.x86_64.rpm I get just plain xterm with mutter and screen refresh is OK. (.xinitrc starts mutter & exec xterm) When I yum update back to: mutter-126.96.36.199-2.fc16.x86_64 clutter-1.7.4-1.fc16.x86_64 cogl-1.7.2-1.fc16.x86_64 And I try the same - then refresh of the xterm screen again shows problems. Note - no gnome-shell has been involved - as getting this thing running would probabably require to downgrade whole system to some June rawhide repo.
Comment 10 Peter Robinson 2011-07-15 06:16:46 EDT
> Note - no gnome-shell has been involved - as getting this thing running would > probabably require to downgrade whole system to some June rawhide repo. It was working just fine as of a couple of days ago
Comment 11 Zdenek Kabelac 2011-07-18 13:56:39 EDT
Anything new here ? Am I still the only one who sees this problem with latest mutter3.1 ? Unfortunately at the same time metacity is also broken in Rawhide (coredumps) - thus there is no way to use gnome environment on my desktop without refresh issues (i.e. 2D fallback version)
Comment 12 Matěj Cepl 2011-07-19 10:16:34 EDT
(In reply to comment #11) > Anything new here ? > > Am I still the only one who sees this problem with latest mutter3.1 ? No, you are not. In my case the redraw has couple of seconds delays sometimes. But nothing so serious, that it would warrant switch of the window manager.
Comment 13 Zdenek Kabelac 2011-07-19 10:24:23 EDT
Well in my (In reply to comment #12) > (In reply to comment #11) > > Anything new here ? > > > > Am I still the only one who sees this problem with latest mutter3.1 ? > > No, you are not. In my case the redraw has couple of seconds delays sometimes. > But nothing so serious, that it would warrant switch of the window manager. In my case it's not just couple seconds - I often need to click to the window or do some other version to invoke full refresh - otherwise the text in i.e. text editor remains broken and it's confusing (i.e. my fte optimized refreshed areas and thus if mutter forgets to update some portion of screen properly it takes very long time to get properly rendered window again)
Comment 14 Matěj Cepl 2011-07-19 10:33:39 EDT
Although I have to add, I have it with Cantiga.
Comment 15 Adel Gadllah 2011-07-19 12:11:38 EDT
That is probably a clutter bug triggered by http://git.gnome.org/browse/clutter/commit/?id=19b86229831a049e8f337e2d7a7a4782961b664c Basically culling is causing some issues now I still do not know why exactly. Running with CLUTTER_DEBUG=disable-culling should get rid of the artifacts for know. It still might be a bug in gnome-shell and/or mutter but it is definitely not a mesa/driver bug. So reassign to clutter being the most likely offender.
Comment 16 Peter Robinson 2011-07-19 13:00:39 EDT
(In reply to comment #15) > That is probably a clutter bug triggered by > http://git.gnome.org/browse/clutter/commit/?id=19b86229831a049e8f337e2d7a7a4782961b664c > > Basically culling is causing some issues now I still do not know why exactly. > > Running with CLUTTER_DEBUG=disable-culling should get rid of the artifacts for > know. > > It still might be a bug in gnome-shell and/or mutter but it is definitely not a > mesa/driver bug. So reassign to clutter being the most likely offender. Why is it suddenly causing issues when that code is in F-15 and not causing problems?
Comment 17 Matěj Cepl 2011-07-20 06:02:48 EDT
(In reply to comment #15) > Running with CLUTTER_DEBUG=disable-culling should get rid of the artifacts for > know. It kind of does, but I have still multi-seconds delay when switching between tabs in gnome-terminal.
Comment 18 Zdenek Kabelac 2011-07-20 10:46:11 EDT
(In reply to comment #15) > That is probably a clutter bug triggered by > http://git.gnome.org/browse/clutter/commit/?id=19b86229831a049e8f337e2d7a7a4782961b664c > > Basically culling is causing some issues now I still do not know why exactly. > > Running with CLUTTER_DEBUG=disable-culling should get rid of the artifacts for > know. > > It still might be a bug in gnome-shell and/or mutter but it is definitely not a > mesa/driver bug. So reassign to clutter being the most likely offender. I've stared my whole user environment with CLUTTER_DEBUG=disable-culling and AFAICS - there is no change in my desktop behaviour. i.e. xterm still is missing refresh for 'less' command.
Comment 19 Zdenek Kabelac 2011-07-24 13:03:07 EDT
As I've made valgrind trace which has revealed couple errors in mesagl/cluter/cogl usage - it might be useful to take a look at Bug 672117 Comment 30 attachment 514776 [details].
Comment 20 Matěj Cepl 2011-08-04 04:28:32 EDT
With these packages bradford:~ $ rpm -qa clutter mesa\* kernel xorg-x11-drv-intel xorg-x11-server-Xorg clutter-1.7.6-1.fc16.x86_64 mesa-libGLU-devel-7.11-1.fc16.x86_64 mesa-demos-7.10-5.20101028.fc16.x86_64 xorg-x11-drv-intel-2.15.0-4.fc16.x86_64 mesa-dri-drivers-7.11-0.16.20110620.0.fc16.x86_64 mesa-dri-llvmcore-7.11-0.16.20110709.0.fc15.x86_64 mesa-dri-filesystem-7.11-1.fc16.x86_64 mesa-libGL-7.11-1.fc16.x86_64 xorg-x11-server-Xorg-188.8.131.52-9.20110510.fc16.x86_64 mesa-libGL-devel-7.11-1.fc16.x86_64 kernel-3.0.0-1.fc16.x86_64 mesa-libGLU-7.11-1.fc16.x86_64 bradford:~ $ I cannot observe the issue anymore. I have still CLUTTER_DEBUG=disable-culling in my environment. I will try to eliminate it in the next step.
Comment 21 Zdenek Kabelac 2011-08-04 05:31:57 EDT
I've these: # rpm -qa clutter mesa\* kernel xorg-x11-drv-intel gnome-shell kernel-3.1.0-0.rc0.git15.1.fc17.x86_64 mesa-libGL-devel-7.11-1.fc17.x86_64 mesa-dri-filesystem-7.11-1.fc17.x86_64 mesa-dri-drivers-7.11-2.fc17.x86_64 mesa-libGLU-7.11-1.fc17.x86_64 kernel-3.1.0-0.rc0.git17.1.fc17.x86_64 mesa-debuginfo-7.11-1.fc17.x86_64 gnome-shell-3.1.4-1.fc16.x86_64 mesa-libGLU-devel-7.11-1.fc17.x86_64 clutter-1.7.6-1.fc16.x86_64 mesa-libGL-7.11-1.fc17.x86_64 xorg-x11-drv-intel-2.15.0-4.fc16.x86_64 I can easily observe the problem with xterm. Also now I'd have said that refresh has got significantly slower in my 'FTE' text editor (no packaged in rpm) where I could easily see text line drawing on the startup - something I've not been noticing before. Another annoying issue which is still persistent even while typing this BZ text is that I can see 'one letter behind' when writing this text. i.e. I see 'space' instead of letter.
Comment 22 Adel Gadllah 2011-08-15 15:02:20 EDT
This should be fixed in clutter master now (which will be in 1.7.9)
Comment 23 Kjartan Maraas 2011-08-22 06:49:45 EDT
Running with clutter-1.7.10 here now and I still see the same problems mentioned above. Ways to reproduce: - open firefox with two tabs and switch back and forth between them until a redraw glitch appears - same with xterm and gnome-terminal and just typing / scrolling through content - sometimes when I try to unlock the screen it shows the unlock screen dialog without a label. "Password:" is not shown
Comment 24 Zdenek Kabelac 2011-08-26 19:43:40 EDT
(In reply to comment #22) > This should be fixed in clutter master now (which will be in 1.7.9) I've tried clutter-1.7.10-1.fc16.x86_64.rpm build from koji - and I've got completely broken desktop - not only refresh was missing - but the whole windows movement locked weird. Thus I'm pretty sure 1.7.10 does not fix this issue - or most probably makes it even worse - I'd to revert to clutter-1.7.6-1.fc16.x86_64.rpm - which is known to be buggy - but it's a least a little bit usable - 1.7.10 is simply unusable.
Comment 25 Hans de Goede 2011-08-31 15:49:48 EDT
I'm seeing this too, I really wish this bug would get some more attention it is really annoying. Note I'm seeing it on 2 fully up2date F-16 systems, one with Intel SNB graphics, and one with an nvidia card (with nouveau). And I heard the same complaint form a friend with ATI graphics. I was hoping the gnome-3.1.90 version would fix things, but no such luck. I'm proposing this as a Fedora 16 blocker, we really cannot ship a relealse with such serious UI issues/ redraw problems. For anyone who thinks I'm exaggerating I invite you to run with xterm in stead of gnome-terminal as your terminal for a day and then get back to me.
Comment 26 Hans de Goede 2011-08-31 15:51:23 EDT
Some more info: I've added "export CLUTTER_DEBUG=disable-culling" to /etc/gdm/Xsession, to ensure it would be set right from the start, and it does make things better, but it does not completely eliminate the problem.
Comment 27 Hans de Goede 2011-09-01 05:16:02 EDT
And more info: I just noticed on my nouveau using laptop, that if I've 2 overlapping xterm's and the lower one of them is getting constantly updated (yum download progress), that then the raised on only gets updated in the area where it overlaps with the lower one, so scrolling in my text editor joe) lead to the part of the txt file I was editing which overlapped with the lower terminal scrolling, and the other part staying still, leading to a really unreadable result.
Comment 28 Zdenek Kabelac 2011-09-01 05:58:25 EDT
I'm starting to believe gnome-shell developers do not use their own product as there is no other explanation, why such IMHO very annoying issue could be ignored for 3 months...
Comment 29 Rui Matos 2011-09-01 07:42:58 EDT
(In reply to comment #26) > Some more info: > > I've added "export CLUTTER_DEBUG=disable-culling" to /etc/gdm/Xsession, to > ensure it would be > set right from the start, and it does make things better, but it does not > completely eliminate the problem. Maybe it does the same, didn't check, but I use the CLUTTER_PAINT env var, not CLUTTER_DEBUG. On my nouveau if I run gnome-shell under "export CLUTTER_PAINT=disable-clipped-redraws:disable-culling" all seems fine.
Comment 30 Zdenek Kabelac 2011-09-01 07:58:58 EDT
(In reply to comment #29) > (In reply to comment #26) > > Some more info: > > > > I've added "export CLUTTER_DEBUG=disable-culling" to /etc/gdm/Xsession, to > > ensure it would be > > set right from the start, and it does make things better, but it does not > > completely eliminate the problem. > > Maybe it does the same, didn't check, but I use the CLUTTER_PAINT env var, not > CLUTTER_DEBUG. On my nouveau if I run gnome-shell under "export > CLUTTER_PAINT=disable-clipped-redraws:disable-culling" all seems fine. Great, the first thing which really does make it look better for me.
Comment 31 Hans de Goede 2011-09-01 10:08:42 EDT
(In reply to comment #30) > (In reply to comment #29) > > Maybe it does the same, didn't check, but I use the CLUTTER_PAINT env var, not > > CLUTTER_DEBUG. On my nouveau if I run gnome-shell under "export > > CLUTTER_PAINT=disable-clipped-redraws:disable-culling" all seems fine. > > Great, the first thing which really does make it look better for me. Same here, this really helps. Which I guess also proves that this really is a clutter issue. I'll try running with just disable-clipped-redraws for a while to help narrow this down.
Comment 32 Matěj Cepl 2011-09-01 11:13:24 EDT
I have put (after advice of halfline about what's loaded where) this variable to ~/.bash_profile and I can confirm that I see my gnome-terminal behaving sanely again. THANK YOU.
Comment 33 Adam Williamson 2011-09-01 14:17:03 EDT
I believe this issue isn't hardware specific and is affecting just about everyone; people seem to be just living with it. I'm seeing it on nouveau, and I've seen others report it with radeon. Redraws simply don't always seem to complete reliably. For me, common reproducers are scrolling back through a conversation in gedit, or switching terminal tabs in gnome-terminal - I'll often wind up with some sort of weird meld between the two tabs. With the recent GNOME 3.1.90 update, it's often the case that if I have a terminal window in front of a Firefox window, and I click the Firefox title bar to switch from the terminal to the Firefox window, the terminal is still displayed above Firefox and I have to click the Firefox title again. Dropping [Crestline] from the summary, adding commonbugs keyword. We could really do with a fix for this.
Comment 34 Adam Williamson 2011-09-01 19:30:23 EDT
the terminal-window-stays-above-other-window bug seems to be different, FWIW, as it still happens after the workaround. I'll file it separately, I guess.
Comment 35 Hans de Goede 2011-09-02 02:31:07 EDT
As promised I've run with just: CLUTTER_PAINT=disable-clipped-redraws That didn't last long, the effects are both fascinating and terrible at the same time while editing a file in joe in a xterm, I gut really sow screen updates, about 1 / sec. But it also seemed to remember the last 3 updates and continuously replay them. So if I moved the cursor up 2 lines, I would see it jump down 2 lines again, move up, move up. Or type 2 letters, see the line without these 2 letters, 1 added the other added. Notes: 1) I waited for 15 seconds for this to stop (with my hands away from the keyboard) 2) Despite being Dutch, no I've not smoked anything funny (never do), this is really happening I'm not imagining it. I've a feeling that comment 19, with the valgrind stuff might be on to something, this is so funky it could be memory corruption, otoh it could just be a logic bug. I also tried using just: CLUTTER_PAINT=disable-culling Better then no CLUTTER_PAINT at all but it does not completely fix this. CLUTTER_PAINT=disable-clipped-redraws:disable-culling, does completely fix this for me.
Comment 36 Hans de Goede 2011-09-02 02:35:23 EDT
(In reply to comment #34) > the terminal-window-stays-above-other-window bug seems to be different, FWIW, > as it still happens after the workaround. I'll file it separately, I guess. He, were did you put the workaround? Depending on where you put it it could be (*) that gnome-shell / mutter itself is not using it, only the apps you are starting. Try putting it in /etc/gdm/Xsession directly under the ". /etc/X11/xinit/xinitrc-common" line, and be sure to make it an export, ie: # HACK HACK export CLUTTER_PAINT=disable-clipped-redraws:disable-culling But I'm sure you know that already :) *) I've no clue if this is true or not, it is just that I'm not seeing / cannot reproduce this terminal problem.
Comment 37 Adam Williamson 2011-09-02 02:59:58 EDT
I put it in ~/.bash_profile . The terminal issue seems to be new in 3.1.90, so if you haven't pulled that from Koji, you won't see it.
Comment 38 Hans de Goede 2011-09-02 03:10:36 EDT
(In reply to comment #37) > I put it in ~/.bash_profile . > > The terminal issue seems to be new in 3.1.90, so if you haven't pulled that > from Koji, you won't see it. I do have 3.1.90 from koji, I pulled that from there before I started to make noise about this, as I was hoping that it would fix this (and many others with me I guess). Can you humor me and try moving the export to /etc/gdm/Xsession ?
Comment 39 Zdenek Kabelac 2011-09-02 04:58:50 EDT
To leave the base X11 files untouched one could create a new separate executable file with this HACK like this: /etc/X11/xinit/xinitrc.d/10-clutter-hack.sh #!/bin/sh export CLUTTER_PAINT=disable-clipped-redraws:disable-culling
Comment 40 Emmanuele Bassi 2011-09-02 11:45:09 EDT
[this would help if it were pushed to the upstream bugzilla product.] anyway: as far as I can read from the comments, this only happens on application windows, not on the shell's chrome (pure Clutter actors). this would point to an issue in Mutter *or* in the Mesa GLX_EXT_texture_from_pixmap extension. since we know that using CLUTTER_PAINT=disable-clipped-redraws:disable-culling "fixes" it by redrawing the whole scene instead of just the damaged region, let's try to narrow it down again. it would help if somebody tested using: export CLUTTER_PAINT=redraws and verified if there are rectangles painted where nothing should be painted.
Comment 41 Adam Williamson 2011-09-02 13:35:36 EDT
hans: the workaround is clearly working for me as I don't have redraw issues with it in place. just the terminal thing.
Comment 42 Michael Schwendt 2011-09-13 17:24:35 EDT
1) The disable-culling workaround does work for me, too. 2) For further testing, I have disabled the work-around again and have enabled the rectangles from comment 40. Prove: http://mschwendt.fedorapeople.org/tmp/fedora-clutter-bug-720605-2.png To double-check that I can still reproduce the issues, I have tried to downgrade clutter from clutter-1.7.90-1.fc16.x86_64 kernel-3.1.0-0.rc6.git0.0.fc16.x86_64 to the previous release, and I could reproduce the issues. Simply running 'll' a couple of times in a xterm occasionally stops with some areas of the terminal being empty. Then I updated to the latest clutter again and could still reproduce the issue. However, once I turnt on the rectangles, I cannot reproduce the issue. The red rectangles that are drawn around the areas where I'm active (e.g. in Emacs) appear with a plausible size. Always. Nothing too much, nothing missing.
Comment 43 Adam Williamson 2011-09-13 18:03:56 EDT
just checked quickly, I'm still seeing this bug with: clutter-1.7.90-1.fc16.x86_64 kernel-3.1.0-0.rc6.git0.0.fc16.x86_64 haven't tested with CLUTTER_PAINT=redraws yet to see where the rectangles go.
Comment 44 Dan Krejsa 2011-09-13 23:38:50 EDT
Hi, In Fedora 15 I have been seeing quite frequent incomplete redraws and other screen glitches, primarily when using Firefox, but occasionally (much less commonly) in gnome terminal. I tried the /etc/X11/xinit/xinitrc.d/10-clutter-hack.sh #!/bin/sh export CLUTTER_PAINT=disable-clipped-redraws:disable-culling workaround for this issue and it seems to make those screen glitches not occur (as far as I can tell in a few minutes of playing around). They also seem not to occur in fallback mode. I'll try with just 'CLUTTER_PAINT=redraws' next.
Comment 45 Dan Krejsa 2011-09-13 23:50:51 EDT
Hi, Well, those red rectangles are both interesting and disconcerting, but as far as I can see, with 'CLUTTER_PAINT=redraws', the kind of incomplete redraws in Firefox that I would see without it (particularly when scrolling and/or selecting text) do not occur. I'll keep this mode on for a while just in case I hit a lucky spell.
Comment 46 Dan Krejsa 2011-09-14 00:13:58 EDT
I did see one instance of a horizontal line redraw defect running with CLUTTER_PAINT=redraws, however that was just one instance in a period when I would typically see many such defects. Don't ask me what to conclude from this, though. For what it is worth I use the proprietary nvidia drivers; the graphics device is the GeForce Go 7900 GS.
Comment 47 Adam Williamson 2011-09-14 14:19:16 EDT
this is being worked on at https://bugzilla.gnome.org/show_bug.cgi?id=657071 , and Owen has a theory - yay.
Comment 48 Adam Williamson 2011-09-14 14:19:52 EDT
proposing as Beta NTH as it'd be kinda nice to fix this for Beta, especially for lives.
Comment 49 Peter Robinson 2011-09-14 19:14:48 EDT
reassigning to mutter to match upstream bug
Comment 50 Fedora Update System 2011-09-14 19:25:01 EDT
mutter-184.108.40.206-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/mutter-220.127.116.11-1.fc16
Comment 51 Fedora Update System 2011-09-15 11:14:50 EDT
Package mutter-18.104.22.168-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mutter-22.214.171.124-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/mutter-126.96.36.199-1.fc16 then log in and leave karma (feedback).
Comment 52 Adam Williamson 2011-09-16 14:24:16 EDT
Discussed at the 2011-09-16 NTH review meeting. Accepted as NTH due to the obvious visual impact on the live image especially. (Note I think I cheated and got this pulled into RC1 already.)
Comment 53 Matěj Cepl 2011-09-16 18:34:21 EDT
*** Bug 737850 has been marked as a duplicate of this bug. ***
Comment 54 Tim Flink 2011-09-16 22:35:48 EDT
Discussed in the 2011-09-16 blocker review meeting. Accepted as an NTH bug for Fedora 16 beta because many people are hitting it, it would be nice to have fixed for beta and a fix is available.
Comment 55 Fedora Update System 2011-09-19 19:52:04 EDT
mutter-188.8.131.52-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Comment 56 Dan Krejsa 2011-09-19 20:54:35 EDT
Is there any chance of getting this fix into Fedora 15?
Comment 57 Adam Williamson 2011-09-19 21:48:24 EDT
dan: I'm pretty sure this bug doesn't affect f15. if you have some kind of corruption issue with f15, please file a separate bug.
Comment 58 David Batson 2011-11-18 21:15:16 EST
FWIW, I have some video tearing in Fedora 15 Gnome and the above code from comment #29 fixes this. This is on a Lenovo X220 ThinkPad (Sandy Bridge) with Intel HD 3000 graphics. I found this from a comment made on the Arch Forums regarding Gnome 3 tearing. https://bbs.archlinux.org/viewtopic.php?pid=1017705#p1017705 The second line of code from the Arch Forum: "CLUTTER_VBLANK=True" did not seem to have any effect on my X220 afaict. I discovered an alternative fix for video tearing is to use Gnome Classic with Compiz.
Comment 59 David Batson 2011-11-18 21:31:29 EST
Looking at the Gnome bug report linked to in comment #47, the second comment there appears to be why I this is useful in Fedora 15 Gnome for improving video quality. >> CLUTTER_PAINT=disable-clipped-redraws:disable-culling >Furthermore I found that running with this env var makes gnome-shell vsync >properly while it doesn't without it.
Comment 60 Dan Krejsa 2011-11-19 11:40:45 EST
A point of interest. I recently upgraded from Fedora 15 to Fedora 16, and was still experiencing the same sort of partial redraws I had seen in Fedora 15. Then I switched from the proprietary nvidia drivers (as packaged by atrpms) to the nouveau driver, and the symptoms appear to have gone away. I guess this means that either - there is a bug in the proprietary nvidia driver, or - there is some legitimate difference in how the nvidia driver interacts with the higher levels of the graphics stack that makes a bug in the latter more apparent.
Comment 61 Edouard Bourguignon 2012-05-10 14:03:17 EDT
problem persists with mutter-3.4.1-2.fc17.x86_64 and nvidia driver. Workaround is to use KDE...
Comment 62 Paul Alesius 2012-05-28 08:18:18 EDT
Still occurs with mutter-3.4.1-3.fc17.x86_64 and nvidia drivers. To me it's most noticeable with gnome-terminal. Have to select text and random stuff like that and it eventually refreshes fully, but it's very annoying.
Comment 63 Leonidas Georgopoulos 2012-06-01 17:28:07 EDT
Still present with: Installed Packages clutter.i686 1.8.4-2.fc16 @updates clutter-gst.i686 1.4.4-1.fc16 @updates clutter-gtk.i686 1.0.4-1.fc16 @fedora clutter-gtk010.i686 0.10.8-5.fc16 @fedora compiz.i686 0.9.5.92.1-0.2.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc16 @updates compiz-fusion-extras.i686 0.9.5.92-1.fc16 @updates compiz-fusion-extras-gconf.i686 0.9.5.92-1.fc16 @updates compiz-gnome.i686 0.9.5.92.1-0.2.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc16 @updates compiz-gtk.i686 0.9.5.92.1-0.2.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc16 @updates compiz-plugins-main.i686 0.9.5.92-1.fc16 @updates compiz-plugins-main-gconf.i686 0.9.5.92-1.fc16 @updates compizconfig-backend-gconf.i686 0.9.5.92-0.1.gitf9ac54186bb62d00b28adc335220dba39a04b702.fc16 @updates compizconfig-python.i686 0.9.5.94-0.1.gitb02413d104573641f293d535537821316ecb8f36.fc16 @updates firefox.i686 12.0-1.fc16 @updates mutter.i686 3.2.2-1.fc16 @updates akmod-nvidia.i686 1:295.53-1.fc16.1 @rpmfusion-nonfree-updates xorg-x11-drv-nvidia.i686 1:295.53-1.fc16 @rpmfusion-nonfree-updates kmod-nvidia-3.3.7-1.fc16.i686.PAE.i686 1:295.53-1.fc16.1 @rpmfusion-nonfree-updates kmod-nvidia-PAE.i686 1:295.53-1.fc16.1 @rpmfusion-nonfree-updates but the workaround is valid.
Comment 64 Marcin Kulik 2013-01-26 20:23:56 EST
Still happening on gnome-terminal. Mutter 3.6.2 on Intel HD 4000.
Comment 65 atomic.quark 2013-08-19 12:17:26 EDT
I'm still having this problem (and not being helped with CLUTTER_PAINT=disable-clipped-redraws:disable-culling). I'm on FC19 using xmonad. The problems don't seem to appear in Gnome 3 or under nouveau iirc. Installed Packages akmod-nvidia.x86_64 1:319.32-2.fc19 @rpmfusion-nonfree-updates clutter.x86_64 1.14.4-4.fc19 @updates gnome-terminal.x86_64 3.8.4-1.fc19 @updates mutter.x86_64 3.8.4-1.fc19 @updates xorg-x11-drv-nvidia.x86_64 1:319.32-7.fc19 @rpmfusion-nonfree-updates Available Packages clutter.i686 1.14.4-4.fc19 updates kmod-nvidia.x86_64 1:319.32-2.fc19.4 rpmfusion-nonfree-updates mutter.i686 3.8.4-1.fc19 updates
Comment 66 Emmanuele Bassi 2013-08-19 12:23:14 EDT
(In reply to atomic.quark from comment #65) > I'm still having this problem (and not being helped with > CLUTTER_PAINT=disable-clipped-redraws:disable-culling). I'm on FC19 using > xmonad. The problems don't seem to appear in Gnome 3 or under nouveau iirc. neither gnome-terminal nor xmonad use Clutter, so I'm not entirely sure how can this be the same issue. if it does not happen under GNOME, then it means it's been fixed, actually,
Comment 67 atomic.quark 2013-08-19 12:28:48 EDT
Ah, guess this problem is more likely to be related to xmonad then. Sorry about that. Guess that explains why the hack does nothing for me.
Comment 68 Erik Streb del Toro 2015-07-31 06:26:19 EDT
@email@example.com: In xmonad you have this problem if you are having the SetWMName extension enabled in order to convince Java that xmonad is "LG3D" (which is a deprecated way of working around the gray java windows). But this SetWMName breaks GTK3-apps, see the xmonad FAQ: https://wiki.haskell.org/Xmonad/Frequently_asked_questions#Using_SetWMName This xmonad “bug” has been reported AND solved here: https://bugzilla.redhat.com/show_bug.cgi?id=1061568 https://code.google.com/p/xmonad/issues/detail?id=559