Gala choppy animation in Freya Beta 1

Bug #1355453 reported by Ken Harkey
284
This bug affects 62 people
Affects Status Importance Assigned to Milestone
Gala
Fix Released
High
Tom Beckmann

Bug Description

Several users on google plus have reported choppy animation on the first beta, I made a video to show some of these animations which have been confirmed by a couple other people.

https://plus.google.com/117763153598905243679/posts/iDBYfFTBXhE

Any other files that I may need to upload just ask and it shall be done.

Related branches

Revision history for this message
thndsr (stijnverwaaijen) wrote :

I tried both radeon and fglrx. Doesn't seem to make any difference.

Revision history for this message
Eddie (eddie-imada) wrote :

I'm using Intel HD graphics 2nd generation and i'm experiencing this as well.

Revision history for this message
Mikhail Abbas (mikhail-abbas) wrote :

By the way, this also present when using from the LiveCD too on my Intel HD 4000

Revision history for this message
Ken Harkey (kenny727) wrote :

Should have mentioned I have an intel GMA 965 video card, integrated. Using the intel drivers from the ubuntu main repos.

Revision history for this message
Marden Laairoy (laairoy) wrote :

I have same problem. I try Catalyst and open drives, but not fix it.

Revision history for this message
swizzle (el-ferreira-deactivatedaccount) wrote :

I get choppy animations too.

Gre0 (gre0)
no longer affects: ubuntu
Revision history for this message
UweS (uwes) wrote :

Same problem on VMWare Fusion 6.0.4 on a MacBook Pro 5,5.

Changed in elementaryos:
status: New → Confirmed
Cody Garver (codygarver)
affects: elementaryos → gala
Changed in gala:
importance: Undecided → High
milestone: none → freya-beta2
Revision history for this message
Tom Beckmann (tombeckmann) wrote :

It's relatively hard to tell whether the choppiness is related to framerate or actual choppiness, are we talking about all the animation shown in the videos? Or just e.g. maximize/unmaximize and minimize? Is the unminimize one fine? Is the panel animating smoothly?

Best would be if you could tell me which of these animation types are affected:
- Maximize
- Unmaximize
- Minimize
- Unminimize
- Open
- Close
- Panel animation
- Menu open animation
- Dialog open animation

Revision history for this message
Rory (roryj) wrote :

For me, the problem is gala animations are not mapping to the actual window size. The animation always seems to be to the lower right of the actual window. The only application that works correctly is Google Chrome which makes me guess it is related to GTK+ as chrome uses Aura.

The affected animations are maximizing/unmaximizing with snap or the top right button. Opening a new window into a maximized state is also not correct with the animation appearing to go to the upper left of the window. This is strange because the unminimizing animation works correctly (even though they should be the same animation).

If anyone else wants to confirm this is the problem they are having, increase the gala animation durations (using dconf editor, change org.pantheon.desktop.gala.animations values).

Another bug that may be related is show in the attached image - occasionally when unmaximizing a window with snap, the header bar duplicates and appears larger above. The reason this may be related is that the cursor is attached to this duplicate header bar not the actual window. It's quite hard to explain - I can make a video to show it if needed.

Another problem that needs to be addressed: when minimizing a window, it disappears for a brief moment and then reappears and continues the animation.

I have been messing around trying to find the problem for a while, but I am no gala/mutter expert!

Revision history for this message
Jan Keuper (jan-keuper) wrote :

Just want to chime in. I pretty much experience what roryj described. Another thing that just doesn't feel smooth is window dragging. Sometimes after a fresh boot the animation feels silky smooth, but that's rare. Most of the time it feels like 20-25 fps. I'm running an nVidia GTX 760 with 343.13 proprietary driver from xorg-edgers. I don't have any tearing problems, games also run just fine (aside from one or two titles that just don't want to turn vsync on).

Are there any information I can paste here that would help?

Revision history for this message
Giulio Sant (giulio-sant) wrote :

I experience the described issues on minimize, (un)maximize and menu open animation.

Revision history for this message
Ellie (magnonellie) wrote :

This has affected me in the past but it doesn't seem to be happening any more. Is that just me having a lucky day or is this fixed?

Cody Garver (codygarver)
Changed in gala:
milestone: freya-beta2 → none
Revision history for this message
Rory (roryj) wrote :

This is not a duplicate of bug #1345085 and therefore still not fixed.

Revision history for this message
Indaleto (indaleto) wrote :

The problem persists with or without bumblebee drivers

Revision history for this message
Indaleto (indaleto) wrote :

Just give a little help to future developers:

https://www.youtube.com/watch?v=TNXJJoI6ceU&feature=youtu.be

Revision history for this message
Tom Beckmann (tombeckmann) wrote :

The maximize thing is a problem in the code and not related to the drivers. The offsets are calculated incorrectly for CSD windows, that's why you get the scaling to the wrong position. Fixing this requires patching libmutter to give us a little more info about the window that is being maximized, I still haven't gotten around to do that. I do think that we have a bug for this already though, but I can't remember for sure.

Revision history for this message
Indaleto (indaleto) wrote :

But I have Luna installed in another partition and the problem does not exists. Only in freya

Revision history for this message
Tom Beckmann (tombeckmann) wrote :

As I said, it's related to CSD (client side decorations), which is a new thing in Freya. The same problem exists in luna as well though, but it's a lot less noticeable.

Revision history for this message
David Collins (c3097481) wrote :

What I feel on my system is that the panel is very very smooth. All the animations run great. But the animations of the workspace/windows overview, minimize/unminimize, open/close and switchboard seem to run everytime at about 20fps or something. All the animations in Luna on the same system run flawlessly.

Revision history for this message
Paulo Molina (polochamps2004) wrote :

Alt tabbing is very smooth ~ feels constant 60FPS.
But maximizing/restoring a window is not that smooth. It's flickering like what's described on this bug report.

https://bugs.launchpad.net/gala/+bug/1414304

Revision history for this message
pafosdfkapos (pafosdfkapos) wrote :

This has nothing to do with the drivers.

I know this, because I have installed Compiz and almost everything is a lot smoother with it. Slingshot, Plank and animations are all smooth and look nice, you get the point. I can confirm that like Paulo Molina said, the Alt tabbing is smooth with Gala. So... the problem lies within Gala, not the drivers.

Cody Garver (codygarver)
Changed in gala:
assignee: nobody → Tom Beckmann (tombeckmann)
status: Confirmed → In Progress
milestone: none → loki-beta1
Revision history for this message
Kanishk Dudeja (kanishk-dudeja) wrote :

A video of the problem faced on my system:

https://www.youtube.com/watch?v=GdN9yCvzV-Y

Changed in gala:
status: In Progress → Fix Committed
milestone: loki-beta1 → freya-rc1
Revision history for this message
Ken Harkey (kenny727) wrote :

I saw that the status of this bug has changed and would like to report that I haven't experienced this in quite some time now. Same machine running beta 2 so it seems to have been fixed on my end at the least.

Revision history for this message
Kanishk Dudeja (kanishk-dudeja) wrote :

Has the fix for this been released in the repo? I have upgraded my system. But i am still facing the same issue. https://www.youtube.com/watch?v=GdN9yCvzV-Y

Revision history for this message
Tom Beckmann (tombeckmann) wrote :

@Kanishk: The whole code depends on workarounds because the client side decorations draw their own shadows and don't give us info on how large those shadows are when we are in maximized state. The trick we use is that we remember the size of the shadow back when the window was unmaximized so we can use it later for animating. However, if a window starts maximized as seen in your video, we don't have those infos, so we can only guess what the dimensions may be and because of the CSD we are quite a bit off resulting in that ugly jump. Unfortunately there's nothing we can do about that. We decided that we'll just cross fingers and hope that every window is unmaximized at some point, or at least the majority of windows.

Revision history for this message
Kanishk Dudeja (kanishk-dudeja) wrote :

@Tom: How did it work in Luna then? In Luna, it worked perfectly. :( Animations was a part of why i love ElementaryOS and seeing this broken is going to make my experience unpleasant. :(

Revision history for this message
Tom Beckmann (tombeckmann) wrote :

As I said, it is related to client side decorations. Those are the buttons that are inside the window headerbar. We didn't have those in Luna. This unfortunately is a technical limitation introduced by gtk, we can't do anything about it. Your only option to "fix" this issue would be to disable animations for (un)maximizing, do so by running "gsettings set org.pantheon.desktop.gala.animations snap-duration 0" in a terminal.

Revision history for this message
Kanishk Dudeja (kanishk-dudeja) wrote :

@Tom: When i am on the Desktop, and i simply click on the 'Files' Icon in the plank, it looks horrible. That is a major use case. Most of the times people are going to launch apps/windows from Plank like that.

Revision history for this message
Kanishk Dudeja (kanishk-dudeja) wrote :

@Tom: Also, does it have to do anything with the laptop you you are seeing it on? Because it seemed to work perfectly on my Lenovo Laptop with Luna. Whereas it works like this on my Dell Laptop with Freya Beta.

Revision history for this message
Kanishk Dudeja (kanishk-dudeja) wrote :

" so we can only guess what the dimensions may be" - Isn't there any method to find out the screen width and height. You could simply use that to calculate.

Revision history for this message
Kanishk Dudeja (kanishk-dudeja) wrote :

If you do know of some method which could fix this the right way, please let me know. I'm a developer too and want to work towards fixing this, if it can be fixed.

Revision history for this message
Tom Beckmann (tombeckmann) wrote :

Again, as I said before, it only applies to windows that start maximized (respectively, that have never been unmaximized). Files remembers its last state. So if you open Files, unmaximize it, close Files and open it again, it should be smooth on your desktop as well.

Feel free to investigate libmutter's or gala's code for better solutions, I didn't see any. It's not about screen dimensions, it's about the area that the window occupies for its shadow that we cannot anticipate. You'll see more closely what I mean if you inspect the code and have some values printed.

Revision history for this message
Kanishk Dudeja (kanishk-dudeja) wrote :

Sure. Thanks a lot for responding.

Can you point me to a tutorial which teaches how to set up ElementaryOS in my local system(cloning the git repo), building it and testing it?

Revision history for this message
Alex Viscreanu (alexviscreanu) wrote :

All animations are working quite good. Not at Luna levels but they improved. The problem is that now in the worskpace overview, windows overview and desktop switching animations I'm experiencing some weird flickering with black zones and zones with the desktop wallpaper. It seems like the desktop wallpaper is trying to overlap the windows.

I've tried to record it but when I start recording and i make the animation it stops flickering but the animations remain way slower than before the recording. It doesn't resets until I restart.

If I only record one window, and not any of these animations the still flickering and perform quite good. It's like recording the animations trigger something and stop flickering but with worse performance.

It's a quite strange bug...

Revision history for this message
Marcus Wichelmann (l-admin-3) wrote :

Hm, I had the same issue after I reinstalled my system with the newes image. It did not appear in an old system that has been updated to the newest packages.

But since today the bug is completely away. All I have done before the first start today is installbing bumblebee and bumblebee-nvidia and removing the ~/.Xauthority file. I'll restart later and check if the bug comes back. I hope it doesn't... ;)

Revision history for this message
Marcus Wichelmann (l-admin-3) wrote :

Okay, after a reboot the bug is back... Hm...
Removing the .Xauthority before logging in has no effect. Bumblebee is still installed. Very strange...

Revision history for this message
Marcus Wichelmann (l-admin-3) wrote :

Sorry for spamming! ;)

After I have now tried to record a video with that bug using eidete and gave up, the flickering is away. :) Can anyone reproduce this "fix"? :) Maybe putting gstreamer in the autostart-list is a solution.. :D

Revision history for this message
Danielle Foré (danrabbit) wrote :

If you're experiencing a different issue, please file a new report. This report has been closed. Each issue needs to be its own new report.

Revision history for this message
Kanishk Dudeja (kanishk-dudeja) wrote :

Sorry by mistake changed the status from fix committed to fix released. Didn't mean to do it. Can't undo it.

Changed in gala:
status: Fix Committed → Fix Released
Revision history for this message
Marcus Wichelmann (l-admin-3) wrote :

Did undo it. ;)

Changed in gala:
status: Fix Released → Fix Committed
Revision history for this message
Shahid (dodupersonal) wrote :

Is this fixed yet? I'm facing the same issue on the stable Freya released on April, 11th 2015.

Revision history for this message
Ariel Loyarte (ariel-loyarte) wrote :

The problem is still on Freya stable. Status says "Fix Committed", so I guess there's no fix yet.

Revision history for this message
Ariel Loyarte (ariel-loyarte) wrote :

On Freya stable:
The problem occurs not only for windows that use Client Side Decarations. It happens with every window.
And typing "gsettings set org.pantheon.desktop.gala.animations snap-duration 0" in a terminal disable animations for (un)maximizing (as comment #27 says), but the problem is still there.

Revision history for this message
Ariel Loyarte (ariel-loyarte) wrote :

Problem is on opening animation, not snaping. Just type "gsettings set org.pantheon.desktop.gala.animations open-duration 0" and problem for opening maximized windows is gone.

Revision history for this message
Shahid (dodupersonal) wrote :

Please release the fix! This is so annoying. It's the only reason I'm currently staying off the otherwise beautiful Freya .

Revision history for this message
Kanishk Dudeja (kanishk-dudeja) wrote :

@Shahid: Please respect developers. There is no obligation on the developers to release the fix. Please care enough to read the whole thread.

"The whole code depends on workarounds because the client side decorations draw their own shadows and don't give us info on how large those shadows are when we are in maximized state. The trick we use is that we remember the size of the shadow back when the window was unmaximized so we can use it later for animating. However, if a window starts maximized as seen in your video, we don't have those infos, so we can only guess what the dimensions may be and because of the CSD we are quite a bit off resulting in that ugly jump. Unfortunately there's nothing we can do about that. We decided that we'll just cross fingers and hope that every window is unmaximized at some point, or at least the majority of windows." - Tom Beckmann

Revision history for this message
Shahid (dodupersonal) wrote :

@Kanishk: I do respect the developers. Freya is by far the most beautiful Linux distribution out there. This bug is literally the only thing I find wrong with the OS and it'd be awesome if they could fix this. And I did read the whole thread before commenting. What I understand is that with the trick the developers used in the committed fix, one shouldn't get the bug if he/she has ever unmaximized the window. But as it stands, I get the the jump every time a window is opened maximized. The only fix right now is to either open it unmaximized, maximize it for use and unmaximize it again before closing it. Or turn off the window open animation. Both of which suck. And I know there is no obligation at all on the developers to release the fix. Hence the 'please'.

Changed in gala:
status: Fix Committed → Fix Released
Revision history for this message
Marco Giannini (marco-giannini) wrote :

Some news about the fix? For now the only way di to disable animation :(

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.