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-1.10.99.1-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-1.10.99.1-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-1.10.99.1-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:
Created attachment 512372 [details] xorg.conf (unmodified for quite some time)
Created attachment 512373 [details] Xorg.0.log
(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.
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.
(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?
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).
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
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)
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-3.1.3.1-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.
> 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
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)
(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.
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)
Although I have to add, I have it with Cantiga.
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.
(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?
(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.
(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.
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].
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-1.10.99.1-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.
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.
This should be fixed in clutter master now (which will be in 1.7.9)
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
(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.
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.
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.
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.
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...
(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.
(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.
(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.
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.
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.
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.
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.
(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.
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.
(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 ?
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
[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.
hans: the workaround is clearly working for me as I don't have redraw issues with it in place. just the terminal thing.
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.
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.
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.
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.
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.
this is being worked on at https://bugzilla.gnome.org/show_bug.cgi?id=657071 , and Owen has a theory - yay.
proposing as Beta NTH as it'd be kinda nice to fix this for Beta, especially for lives.
reassigning to mutter to match upstream bug
mutter-3.1.91.1-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/mutter-3.1.91.1-1.fc16
Package mutter-3.1.91.1-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-3.1.91.1-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/mutter-3.1.91.1-1.fc16 then log in and leave karma (feedback).
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.)
*** Bug 737850 has been marked as a duplicate of this bug. ***
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.
mutter-3.1.91.1-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Is there any chance of getting this fix into Fedora 15?
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.
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.
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.
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.
problem persists with mutter-3.4.1-2.fc17.x86_64 and nvidia driver. Workaround is to use KDE...
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.
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.
Still happening on gnome-terminal. Mutter 3.6.2 on Intel HD 4000.
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
(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,
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.
@atomic.quark: 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