Red Hat Bugzilla – Bug 977391
Gnome Shell tearing on Sandy Bridge
Last modified: 2015-02-17 10:40:27 EST
Created attachment 764566 [details]
gnome-shell-perf-tool --perf=core --perf-iters=3 --replace > gnome_test.txt
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Tested on Fedora 19 installed and updated yesterday but all of logs/tests/videos come from Live Fedora 19 made of Fedora-Live-Desktop-x86_64-19-TC6-1.iso
[liveuser@localhost ~]$ uname -a
Linux localhost 3.9.5-301.fc19.x86_64 #1 SMP Tue Jun 11 19:39:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[liveuser@localhost ~]$ glxinfo | grep rendere
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset
[liveuser@localhost ~]$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
Videos of interest:
*_006* - F18, animations not perfect but way snappier than what's in F19
*_004* - automatic gnome performance test; note inconsistency in animation smoothness - transparent windows sometimes much smoother than non-transparent ones in same number
*_001* from 0:18 - best shows the clunkiness of the animation
I don't understand this bug ... I have watched the videos but could not spot any slowness can you be a bit more specific? What treacly do you perceive as not smooth?
(In reply to drago01 from comment #2)
> I don't understand this bug ... I have watched the videos but could not spot
> any slowness can you be a bit more specific? What treacly do you perceive as
> not smooth?
The Activities in/out animation happens in visible steps i.e. it is not smooth.
I was afraid it will be hard to depict using 30 FPS videos. It's generally hard to talk the matters of smooth animations within Linux community as it seems people either settled for choppy animations or never seen a true 60 FPS / 60 steps or even 30 FPS /30 steps animations. No pun, or whatever, intended. I've just been there before.
I'll try to get through with this anyway by braking it up.
The animation = Activities in/out animation.
Activities out animation = the animation while leaving the Activities view
F18 videos are those with less icons on the launcher.
1. The animation happens in visible steps i.e. it is not smooth.
2. #1 is much more evident in F19 than in F18.
3. #1 is much more evident during the Activities out animation.
4. The issue looks a bit like a problem with malfunctioning/lack of Vertical Synchronization to a layman like me. Or windows / UI elements interfering with each other - see the #5. (it happens in Unity a lot, BTW).
5. Just before the Activities out animation ends pieces of a window further to the bottom of the window stack is visible for a brief moment i.e. while triggering the animation with a full-screen Nautilus window in the foreground and a Firefox window in the background (also maximized) just before the Ativities out animation ends I see a piece of Firefox toolbar.
6. Clearly the animation takes longer in F19 compared to F18, as all of my videos show, consistently.
7. Clearly the animation behaves inconsistently (fast or slow - with or without visible steps) during the automatic gnome performance test.
For ease try to pick the worst and best performing ones. If the animation performed like the best performing one in that test I wouldn't have filed the bug report probably.
8. Lastly, in comparison to other Gnome Shell animations The animation is clearly clunky, e.g. when compared to the animation of workspaces 'sidebar' in/out.
The issue is not something 'barely possible to catch'. If you can't see e.g. #6 and #7 there's not much I can do.
Couldn't it be that the steps are actually some poor but deliberate effect like the mouse cursor trail effect?
I've added some screenshots taken during slow-motion playback of some of the videos.
If anyone knows how to look into and tweak the parameters of the Activities in/out animation, please drop me some hints.
(In reply to rimbotede from comment #3)
> (In reply to drago01 from comment #2)
> > I don't understand this bug ... I have watched the videos but could not spot
> > any slowness can you be a bit more specific? What treacly do you perceive as
> > not smooth?
> In short:
> The Activities in/out animation happens in visible steps i.e. it is not
> I was afraid it will be hard to depict using 30 FPS videos. It's generally
> hard to talk the matters of smooth animations within Linux community as it
> seems people either settled for choppy animations or never seen a true 60
> FPS / 60 steps or even 30 FPS /30 steps animations. No pun, or whatever,
> intended. I've just been there before.
That's nonsense. There is a difference between seeing something in a video and experiencing it first hand.
Anyway can you try this patch https://bug697481.bugzilla-attachments.gnome.org/attachment.cgi?id=246664 ?
(In reply to drago01 from comment #5)
> That's nonsense. There is a difference between seeing something in a video
> and experiencing it first hand.
> Anyway can you try this patch
> https://bug697481.bugzilla-attachments.gnome.org/attachment.cgi?id=246664 ?
I know there's a difference and I mentioned the problem myself. But I've decided to include the videos because I've evaluated the issue as possible to depict using videos - see comment #3, video *_004*. The steps are so evident even 30 FPS video catches them.
What's most important, the "ghost windows" trailing behind the actual windows >are almost what I actually see<! Not some video recording half-frames. The only difference is that on the videos and the screenshots they are longer and blured out. I see them shorter and more opaque, which actually makes the experience even worse.
Unfortunatelly I'm not savvy enough to apply a git patch. I doubt it will help since it just adjusts timings and transition time curves. From my tests even changing /usr/share/gnome-shell/js/ui/overview.js
// Time for initial animation going into Overview mode
const ANIMATION_TIME = 0.25;
to 0.10; doesn't solve the problem. The steps are still to few or frames are dropped or there are window trails left behind them, I don't know.
What I know is that The Animation is not like this https://www.youtube.com/watch?feature=player_detailpage&v=4fE88slXObQ#t=558s on my system. Yes, The animation looks better on this guy's recording than what I actually see on my system. The animation in my F18 looks worse than for many youtubers and I settled with it. It looks even worse on F19 - hence the bug report.
OK, lets try this: If you lower your screens resolution (which one are you using btw?) ... does it end up being better? It should drop less/no frames this way.
I use 1680x1050, native, 16:10, notbook display, Thinkpad T500.
I did as you said - tried at 1024x768. The Animation is almost perfect! Except one short stutter in the middle of the animation, but it's minor.
One additional thing. IIRC the animation >was< that perfect for me on the same hardware, 1680x1050 back in 2012/2013 when I first installed Fedora 18.
(In reply to rimbotede from comment #8)
> I use 1680x1050, native, 16:10, notbook display, Thinkpad T500.
> I did as you said - tried at 1024x768. The Animation is almost perfect!
> Except one short stutter in the middle of the animation, but it's minor.
OK that explains why I am not seeing it here (1280x800 on my GM45 based notebook).
> One additional thing. IIRC the animation >was< that perfect for me on the
> same hardware, 1680x1050 back in 2012/2013 when I first installed Fedora 18.
"when I first installed F18" ... F18 shipped with mesa-9.1 and got a 9.2 snapshot later (which gets used in F19 as well). Does reverting to old mesa build (on F18) restore performance?
(In reply to drago01 from comment #9)
> "when I first installed F18" ... F18 shipped with mesa-9.1 and got a 9.2
> snapshot later (which gets used in F19 as well). Does reverting to old mesa
> build (on F18) restore performance?
Yes, it does! Tested on F18 Live version, not updated. The animation is close to perfect at 1680x1050. Even better than the animation in F19 at lowered resolution, and better than on updated F18.
I've also added a new video to show you that the issue is easy to capture and demonstrate on video (*27_001*.mp4)
(In reply to rimbotede from comment #10)
> (In reply to drago01 from comment #9)
> > "when I first installed F18" ... F18 shipped with mesa-9.1 and got a 9.2
> > snapshot later (which gets used in F19 as well). Does reverting to old mesa
> > build (on F18) restore performance?
> Yes, it does! Tested on F18 Live version, not updated. The animation is
> close to perfect at 1680x1050. Even better than the animation in F19 at
> lowered resolution, and better than on updated F18.
OK I have talked to INTEL people and they can't think of a specific change between mesa 9.1 and 9.2 that might have caused this.
Can you bisect it?
OK we have talked about this a bit more can you try disabling gpu powersaving?
I.e set the value in /sys/kernel/debug/dri/0/i915_min_freq to the one in /sys/kernel/debug/dri/0/i915_max_freq ?
And "<otaylor> drago01: for the cpu, you need to change /sys/devices/system/cpu/cpu<n>/cpufreq/scaling_min_freq - to the value of cpuinfo_max_freq though there can be problems with thermal considerations kicking you out of the max frequency"
> Can you bisect it?
I don't know what you mean.
> OK we have talked about this a bit more can you try disabling gpu
> I.e set the value in /sys/kernel/debug/dri/0/i915_min_freq to the one in
> /sys/kernel/debug/dri/0/i915_max_freq ?
I'm sorry but I don't know how to apply the changes you mentioned in Comments #12 and #13.
You can view the value of the files like that (as root):
and set it that way:
echo VALUE > /sys/kernel/debug/dri/0/i915_min_freq
verify that it got set using
Same for the CPU (where <n> is the number of the cpu 0, 1, ..).
On F18 it gives:
root@localhost 0# cat /sys/kernel/debug/dri/0/i915_max_freq
cat: /sys/kernel/debug/dri/0/i915_max_freq: No such device
(In reply to rimbotede from comment #16)
> On F18 it gives:
> root@localhost 0# cat /sys/kernel/debug/dri/0/i915_max_freq
> cat: /sys/kernel/debug/dri/0/i915_max_freq: No such device
OK, thats because of the old GPU .. try the cpu instead.
It did not help at all. There is no perceivable difference, and you know already that I'm pretty sharp :)
I verified the clock settings have been applied before I tested the animation
xxx@localhost ~$ su
root@localhost xxx# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq800000
root@localhost xxx# echo 2267000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
root@localhost xxx# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
root@localhost xxx# echo 2267000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
root@localhost xxx# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq2267000
root@localhost xxx# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq2267000
Notably, after a minute of entering/leaving the Activities view there was no increase in CPU/system temperature compared to normal settings (~47 deg C, ~2000 fan RPM).
An additional hint re F18. May help...
It seems that usually just after I start F18 The animation is almost perfect but soon it gets to the usual state (rather choppy) and never recovers. Until restart.
(In reply to rimbotede from comment #19)
> An additional hint re F18. May help...
> It seems that usually just after I start F18 The animation is almost perfect
> but soon it gets to the usual state (rather choppy) and never recovers.
> Until restart.
I've just confirmed this using lm_sensors, F18. When I boot right to the system fan RPM is 0 and The animation is perfect. When the fan RPM rises to ~1900 RPM (there are no intermediate values), The animation gets choppy. Both seem to coincide.
OK, seems like it is not power management related then.
Can you tray:
MUTTER_DISABLE_MIPMAPS=1 gnome-shell --replace
in a terminal (keep it open), and then try the animations? Are they faster?
(In reply to drago01 from comment #21)
> OK, seems like it is not power management related then.
> Can you tray:
> MUTTER_DISABLE_MIPMAPS=1 gnome-shell --replace
> in a terminal (keep it open), and then try the animations? Are they faster?
No, the animations were not faster. Maybe even slower.
If you ran out of ideas - two additional hints:
a. I recall a game I used to play not so long ago (Amnesia) performed a lot better (like 50%+ better performance) when started right after system restart.
b. Most animations don't suffer from the issue (like the workspaces animation - it's always smooth) but some animations outside of the Activities get worse, like program exit dialogues, e.g. when I try to quit gedit without saving. They also 'unwrap vertically' in steps / with dropped frames.
Right now I'm on fully installed and updated F19 and the problem persists.
Is there any info on the matter, a workaround perhaps. Working with such a desktop is painful.
As I've learned it's a known pet-bug I've changed the title of the bug report.
Exactly asd described here https://bbs.archlinux.org/viewtopic.php?id=118441&p=2
adding the following two lines to /etc/environment:
reduces/eliminates the tearing. However:"It makes the desktop strangely laggy. When I drag a window it always takes a moment to catch up with the mouse."
Another forum topic: http://forums.fedoraforum.org/showthread.php?p=1541466#post1541466
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.