Bug 720605 - Redraws do not always render completely - affects all hardware - workaround: CLUTTER_PAINT=disable-clipped-redraws:disable-culling
Summary: Redraws do not always render completely - affects all hardware - workaround: ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mutter
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: [cat:rendering] AcceptedNTH
: 737850 (view as bug list)
Depends On:
Blocks: F16Beta-accepted, F16BetaFreezeExcept F16Blocker, F16FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2011-07-12 09:01 UTC by Zdenek Kabelac
Modified: 2018-04-11 10:22 UTC (History)
34 users (show)

Fixed In Version: mutter-3.1.91.1-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-19 23:52:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
mc scroll artefact in gnome-terminal (53.90 KB, image/png)
2011-07-12 09:01 UTC, Zdenek Kabelac
no flags Details
xorg.conf (unmodified for quite some time) (4.85 KB, text/plain)
2011-07-12 09:02 UTC, Zdenek Kabelac
no flags Details
Xorg.0.log (33.42 KB, text/plain)
2011-07-12 09:04 UTC, Zdenek Kabelac
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 657071 0 None None None Never

Description Zdenek Kabelac 2011-07-12 09:01:31 UTC
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:

Comment 1 Zdenek Kabelac 2011-07-12 09:02:52 UTC
Created attachment 512372 [details]
xorg.conf  (unmodified for quite some time)

Comment 2 Zdenek Kabelac 2011-07-12 09:04:18 UTC
Created attachment 512373 [details]
Xorg.0.log

Comment 3 Matěj Cepl 2011-07-12 19:35:28 UTC
(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 08:35:32 UTC
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 11:39:52 UTC
(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 09:51:07 UTC
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 17:49:09 UTC
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 09:24:58 UTC
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 09:50:26 UTC
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.

Comment 10 Peter Robinson 2011-07-15 10:16:46 UTC
> 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 17:56:39 UTC
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 14:16:34 UTC
(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 14:24:23 UTC
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 14:33:39 UTC
Although I have to add, I have it with Cantiga.

Comment 15 Adel Gadllah 2011-07-19 16:11:38 UTC
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 17:00:39 UTC
(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 10:02:48 UTC
(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 14:46:11 UTC
(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 17:03:07 UTC
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 08:28:32 UTC
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.

Comment 21 Zdenek Kabelac 2011-08-04 09:31:57 UTC
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 19:02:20 UTC
This should be fixed in clutter master now (which will be in 1.7.9)

Comment 23 Kjartan Maraas 2011-08-22 10:49:45 UTC
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 23:43:40 UTC
(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 19:49:48 UTC
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 19:51:23 UTC
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 09:16:02 UTC
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 09:58:25 UTC
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 11:42:58 UTC
(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 11:58:58 UTC
(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 14:08:42 UTC
(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 15:13:24 UTC
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 18:17:03 UTC
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 23:30:23 UTC
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 06:31:07 UTC
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 06:35:23 UTC
(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 06:59:58 UTC
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 07:10:36 UTC
(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 08:58:50 UTC
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 15:45:09 UTC
[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 17:35:36 UTC
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 21:24:35 UTC
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 22:03:56 UTC
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-14 03:38:50 UTC
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-14 03:50:51 UTC
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 04:13:58 UTC
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 18:19:16 UTC
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 18:19:52 UTC
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 23:14:48 UTC
reassigning to mutter to match upstream bug

Comment 50 Fedora Update System 2011-09-14 23:25:01 UTC
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

Comment 51 Fedora Update System 2011-09-15 15:14:50 UTC
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).

Comment 52 Adam Williamson 2011-09-16 18:24:16 UTC
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 22:34:21 UTC
*** Bug 737850 has been marked as a duplicate of this bug. ***

Comment 54 Tim Flink 2011-09-17 02:35:48 UTC
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 23:52:04 UTC
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.

Comment 56 Dan Krejsa 2011-09-20 00:54:35 UTC
Is there any chance of getting this fix into Fedora 15?

Comment 57 Adam Williamson 2011-09-20 01:48:24 UTC
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-19 02:15:16 UTC
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-19 02:31:29 UTC
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 16:40:45 UTC
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 18:03:17 UTC
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 12:18:18 UTC
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 21:28:07 UTC

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-27 01:23:56 UTC
Still happening on gnome-terminal. Mutter 3.6.2 on Intel HD 4000.

Comment 65 rofer 2013-08-19 16:17:26 UTC
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 16:23:14 UTC
(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 rofer 2013-08-19 16:28:48 UTC
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 del Toro Streb 2015-07-31 10:26:19 UTC
@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


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