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

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.

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

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.

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

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

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.

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.

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;

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... ?

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).

- 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 ?

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.

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.

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

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.

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

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

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.

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

Fix released in Compiz Main Plugins 0.9.7.2

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.