[regression] Animations of large or full-screen windows skip frames (not smooth)

[Omer Akram]

The issue here appears mostly when minimizing/restoring full screen windows. The animation is no longer smooth when using compiz 0.9.7 (precise) or ppa:vanvugt/compiz (oneiric). It appears the problem is the combination of two facts:
  1. The minimize/restore animations use only regional damage logic, not full screen.
  2. The new compiz code needs to call glFinish in order to eliminate tearing. But it only needs to call glFinish for regional damage, not full screen damage.

WORKAROUND:
Run ccsm
Go to Workarounds
Enable "Force full screen redraws (buffer swap) on repaint"

THE CORRECT SOLUTION:
The ideal long-term solution to this problem is described by bug 901097. That will allow us to use glXSwapBuffers (and glXSwapIntervalSGI) on every frame and avoid the need to call glFinish (because we no longer need to call glXWaitVideoSyncSGI).

A QUICK SOLUTION:
There are really two options for a quick solution:
(a) Modify the animation plugin to use full-screen damage, and hence use the high-performance code path during animations; or
(b) Modify composite to detect when the regional damage is large (say >= one third of the screen) and automatically switch to full-screen damage mode.
... or both?

ORIGINAL DESCRIPTION:
using nvidia binary driver one precise with gtx9800+ with the release candidate of compiz 0.9.7 the minimize/raise animation feels slow if you have a few apps opened.. I then reverted compiz to stable version of precise and didn't notice the issue.

[Ivan Katanović (igadmile-deactivatedaccount)]

same here. especially with maximized apps (most obvious with chromium). I was using vanvugt compiz ppa on onerick, and i think that this branch made animations laggy:
https://code.launchpad.net/~vanvugt/compiz-core/fix-880707.2

It's great branch and fixes vsync issues, but i think that maybe has something with this, especially revision 2900 which fixed animations to last as they should, but affected performance.

I have nvidia too. (g105 m binary driver)

Now i'm on precise and compiz 0.9.7

i'll try vanvugt ppa on onerick again to check again if something from there causes this.

[Ivan Katanović (igadmile-deactivatedaccount)]

ok, I've made fresh install of onerick and updated it, then added ppa:vanvugt/compiz. minimize/maximize animations are definetley laggyer with it.

[Daniel van Vugt (vanvugt)]

Please elaborate on "laggy". Do you mean the animation takes longer or skips frames (doesn't look smooth)?

I had a couple of fixes in mind for the latter issue, but was hoping to not need to touch that code again in this release. One possible fix is trivial and if it works then great. The other potential fix is non-trivial and probably safer to defer.

[Ivan Katanović (igadmile-deactivatedaccount)]

animations skips frames and isn't smooth. before revision 2900 it took longer. It's really visible.

[Omer Akram (om26er)]

@Daniel the latter i.e. when you minimize a window you clearly see frames are skipped. that was not happening without 0.9.7

[Daniel van Vugt (vanvugt)]

Thanks Ivan and Omer... I will look into this soon, hopefully.

Ivan: Regarding your comment "before revision 2900 it took longer", that is correct, but not a bug. The fact that the animations ran in slow motion in early revisions of ppa:vanvugt/compiz was a bug, and that is now fixed. Of course, running in slow motion meant you saw more frames and it appeared smoother. However it was a bug because the animation was taking longer than the compiz config option says it should (220 milliseconds by default). If you would like the animation to last longer (and look better) than please run ccsm and change Animations > Minimize Animation > Duration to something higher like 400.

However, skipping frames will also make the animations look bad as I'm sure you both see and agree. This does not affect the duration of the animation, only the number of frames you see. That is something I think I have seen myself and that's what we should try to fix.

[Daniel van Vugt (vanvugt)]

Also keep in mind the basic math of animations...

If your monitor is refreshing at 60Hz then each frame lasts about 16 milliseconds. Therefore if the animation is configured for 220 milliseconds then you should expect to see roughly 13 frames of animation over about one fifth of a second.

Other animations like "Open" default to even shorter times like 120 or 80 milliseconds (these are Ubuntu defaults, not Compiz defaults). So in an animation of 120 milliseconds you will never see more than 7-8 frames, and in the 80ms animations you can't see more than 5 frames. I personally think these defaults are too short and make animations look less nice than they should.

[Sam Spilsbury (smspillaz)]

I've not had a chance to try this, but what do you think about the following fix on the composite plugin? (was reverted a couple of days ago amongst other things)

    timeDiff = compiz::core::timer::timeval_diff (&tv, &mLastRedraw);

    /* handle clock rollback */

    if (timeDiff < 0)
        timeDiff = 0;

    /*
     * Now that we use a "tickless" timing algorithm, timeDiff could be
     * very large if the screen is truely idle.
     * However plugins expect the old behaviour where timeDiff is never
     * larger than the frame rate (optimalRedrawTime).
     * So enforce this to keep animations timed correctly and smooth...
     */

    if (timeDiff > optimalRedrawTime &&
        !reschedule)
        timeDiff = mOptimalRedrawTime;

    painting = true;
    reschedule = false;

    mRedrawTime = timeDiff;

[Daniel van Vugt (vanvugt)]

That's the wrong region of code, I believe. You're working on the assumption that Ivan's theory is correct that it's caused by r2900. But as I detailed in the bug description I think the cause is r2898/2899.

I think I've covered all the bases in the detailed bug description... ?

[Daniel van Vugt (vanvugt)]

I've now tested both theories with actual code changes;

- if (timeDiff > 100)
+ if (timeDiff > priv->optimalRedrawTime && !priv->reschedule)
      timeDiff = priv->optimalRedrawTime;

This causes animations to slow down so they appear smoother on a fast machine, but not smooth enough. This also causes a regression of the slow-motion animations bug when tested on a slow machine (Atom N270). If you want to simulate such a slow machine on a fast one, I suggest maybe insert an 80ms sleep in the PrivateGLScreen::paintOutputs.

- glFinish ();
+ glFlush ();

This solves the bug completely. Animations are fast again, but it causes tearing as hypothesized above. This confirms the suggestions laid out in the bug description, that we need to avoid glFinish during animations, but not in a way that will cause a tearing regression (LP: #755841).

[Sam Spilsbury (smspillaz)]

- if (timeDiff > 100)
+ if (timeDiff > priv->optimalRedrawTime && !priv->reschedule)
      timeDiff = priv->optimalRedrawTime;

Did you ensure that the setting of priv->reschedule happens after this if branch ?

[Daniel van Vugt (vanvugt)]

Oh, I see. No, but I will test that change (another day). Also, that code is far too important to hack at this late stage. All such changes require very careful consideration, and it's not fully fresh in my mind still. I would hope to test it tomorrow or so.

[Daniel van Vugt (vanvugt)]

I've now tested "setting of priv->reschedule happens after this if branch" and it still results in slow-motion animations. And slightly inconsistent animation timing too. There is still dramatically more stutter than using full-screen redraws or changing glFinish --> glFlush.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

Hmm, this bug seems to have become much harder to reproduce with the new faster compiz code (0.9.7.2). But in case it's still a problem for other people I will have to test and design the fix against oneiric (compiz 0.9.6) where the bug is easy to reproduce with my PPA.

[Ivan Katanović (igadmile-deactivatedaccount)]

I've just updated to 0.7.2 from unity-staging ppa and problem is stil there. Maybe slightly less obvious.

[Daniel van Vugt (vanvugt)]

Fix committed into lp:compiz-plugins-main at revision 25, lp:compiz-animation-plugin at revision 395.

[Daniel van Vugt (vanvugt)]

The animation plugin fix resolves this bug. However I am keeping it open in compiz-core still because a better fix will be implemented by fixing bug 901097 later.

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz-plugins-main - 1:0.9.7.0~bzr19-0ubuntu7

---------------
compiz-plugins-main (1:0.9.7.0~bzr19-0ubuntu7) precise-proposed; urgency=low

  [ Łukasz 'sil2100' Zemczak ]
  * debian/patches/shift_954079.patch:
    - cherry picked the shift plugin patch for fixing an issue with compiz crashes
      on right-click. This removes an unused option in the plugin. (LP: #954079)
  * debian/patches/fix_broken_build.patch:
    - fixes the build with the newer compiz
  * debian/patches/vpswitch_953834.patch:
    - don't pass through keystrokes you are using to the active window (LP: #953834)

  [ Didier Roche ]
  * debian/control:
    - bump compiz-dev and libcompizconfig0-dev build-dep for ABI break
  * debian/patches/fix_930192.patch:
    - Animations of large or full-screen windows skip frames (not smooth) (LP: #930192)
 -- Didier Roche <email address hidden> Wed, 21 Mar 2012 11:46:41 +0100

[Daniel van Vugt (vanvugt)]

Fix released in Compiz Main Plugins 0.9.7.2

[MC Return (mc-return)]

Enable "Force full screen redraws (buffer swap) on repaint" workaround works excellent on Intel gfx HW as well.
Enabling this makes Compiz a lot smoother and faster.