Merge lp:~vanvugt/compiz-core/fix-880707.2 into lp:compiz-core/0.9.5

[Daniel van Vugt]

Fix inaccurate frame timing causing tearing and stuttering (LP: #880707) (LP: #92599) (LP: #798868) (LP: #876575) (LP: #755841) (LP: #891744)

Introduced "tickless" frame timing to the composite plugin. This means we no longer need to poll for repaints. Composite only wakes up when a repaint is required and it's the right time to do so. This not only improves vsync accuracy, but also reduces CPU usage and power consumption.

[Tim Penhey (thumper)]

> bool scheduled, painting, reschedule;

Many coding standards say only one variable declaration per line. I'm not entirely sure what the compiz-core one says.

Also, please prefer initializer lists to setting variables in the constructor.

+ scheduled = false;
+ painting = false;
+ reschedule = false;

These should all be in the initializer list.

review: Needs Fixing

[Daniel van Vugt (vanvugt)]

I disagree...

That file already contains multiple variables per line. So I am not violating the existing standard.

And I tried using initializer lists, but gcc gave warnings about variable initialization order. Those =false lines were the only way I could make the warnings go away.

[Sam Spilsbury (smspillaz)]

222 + /*
223 + * Note the use of delay = 1 instead of 0, even though 0 would be better.
224 + * A delay of zero is presently broken due to CompTimer bugs;
225 + * 1. Infinite loop in CompTimeoutSource::callback when a zero
226 + * timer is set.
227 + * 2. Priority set too high in CompTimeoutSource::CompTimeoutSource
228 + * causing the glib main event loop to be starved of X events.'

Just use the delay of zero and mark the other branches as prerequisites to this one :)

[Sam Spilsbury (smspillaz)]

Oh, it might also be good to get this code into unit tests, since regressions that could be introduced on frame timing would end up very difficult to debug down the road.

Feel free to send me an email about it, and I'll work on it next week. Thanks for all this, its excellent :)

[Daniel van Vugt (vanvugt)]

> Just use the delay of zero and mark the other branches as prerequisites to
> this one :)

I tested a delay of zero. While it made a huge difference in the old composite code (and exposed the CompTimer bugs), using 0 instead of 1 makes no perceivable performance difference in this new version (tested with fixes for CompTimer applied). So maybe my comment is a bit wrong and should not say "even though 0 would be better". In fact, in theory, a delay of zero would increase CPU usage. And since it provides no perceivable benefit any more, I don't think we should aim to change it to zero.

Also, creating dependencies on other branches when you don't need to is not ideal. I would prefer to keep things simple as they are...

[Tim Penhey (thumper)]

The reason you get warnings in the initializer list is that the member variables are initialized in the order that they are declared in the class. The initializer list expects that the order in the list is the same as the order that they are defined. If you don't, it is possible that a developer would assume that something earlier in the initializer list was initialized when in fact it wasn't.

Sam, what does the compiz coding standards say about initializer lists (if anything)?

[Daniel van Vugt (vanvugt)]

Awesome. Testing with NVIDIA-280, this fix appears to solve bug 92599 and bug 888039.

[Daniel van Vugt (vanvugt)]

Found a problem when testing with "nouveau". Nouveau advertises support for GLX_SGI_video_sync, however it is quietly disabled by default and returns immediately. This causes the code in this proposal to attempt to run unthrottled at 1000 FPS, which obviously is a little laggy.

The workaround for nouveau is in /etc/X11/xorg.conf:
Section "Device"
 Identifier "My Graphics"
 Option "GLXVBlank" "on"
EndSection

However, I will have to build a workaround into this proposal so that users don't need to edit xorg.conf.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Or - query upstream as to why it is disabled? Maybe it's something we
can safely distropatch, they already have it in the pipes?

[Daniel van Vugt (vanvugt)]

I will research the issue with nouveau separately. However it's now clear that we need to occasionally expect graphics drivers to be a little broken. Compiz should be able to handle it without becoming unusable. I will look at adding detection for such driver problems into compiz (opengl plugin?) today.

[Daniel van Vugt (vanvugt)]

Interestingly, I only realized today that the fix for bug 763005 is a prerequisite for this proposal. It probably wouldn't work otherwise. Lucky the fix for 763005 is already committed...

[Daniel van Vugt (vanvugt)]

This proposal also appears to solve LP: #798868 and LP: #876575.

[Sam Spilsbury (smspillaz)]

This will be merged as soon as the testing branch in https://code.launchpad.net/~smspillaz/compiz-core/compiz-core.fix_880707.2.test/+merge/82961 is complete

[Sam Spilsbury (smspillaz)]

(I also don't like working around driver bugs inside of the opengl plugin since these can break if the driver developers change something. If you need to add a workaround, add it to the workarounds plugin by replacing the GL::getVideoSync function pointer with your work-around wrapper)

[Daniel van Vugt (vanvugt)]

I'm generalizing the "driver bug workaround" today because similar code is needed for all drivers in some circumstances.

[Daniel van Vugt (vanvugt)]

Done. The changes to plugins/opengl/src/screen.cpp are no longer just for nouveau, but now important for all users.

[Daniel van Vugt (vanvugt)]

Major improvement today. Reduced tearing enough to also resolve bug 755841.

[Omer Akram (om26er)]

Daniel, is there a specific reason this change won't make into Precise? I have noticed real positive improvements on on Intel(smooth minimize animations), nvidia-current (no tearing) and nouvea (no tearing)

[Daniel van Vugt (vanvugt)]

Omer, you misinterpreted my comment in bug 880707. What I meant was that this fix is so complex that it won't go into any oneiric updates. But getting it into precise is my absolute top priority.

I agree; the number of improvements this branch brings is much larger than I ever envisioned. I never even noticed the stuttering bugs until I saw they were fixed by this code. It was a nice surprise.

We do absolutely want everyone to have these improvements by the time precise is released. :)

[Sam Spilsbury (smspillaz)]

I'm going to have another look at how we can do automated testing from this branch again tomorrow.

[Daniel van Vugt (vanvugt)]

I already did automate testing... using an army of testers now subscribed to ppa:vanvugt/compiz ;)

OK, maybe you meant a different kind of automated...

[Sam Spilsbury (smspillaz)]

Indeed :)

I've started updating lp:~smspillaz/compiz-core/fix-880707.2.test with the stuff we discussed there earlier. Namely testing for phase (eg, that it doesn't take > 4ms to get from a vblank begin fence to finishing a swapbuffers / paint) and also testing that we don't fall out of phase when we are throttling the framerate with the composite plugin.

I don't really think its possible to be testing for an exact fix to bug 880707 without instantiating a separate opengl context and running out constructs in there, but doing that is going to be far too much effort than its worth really.

Please let me know of any other parts of the composite plugin's code that you think can be tested.

[Sam Spilsbury (smspillaz)]

(correction: lp:~smspillaz/compiz-core/compiz-core.fix_880707.2.test)

[Sam Spilsbury (smspillaz)]

(and thank you for setting up the PPA)

[Daniel van Vugt (vanvugt)]

Comments in the other branch.

[Daniel van Vugt (vanvugt)]

More work may be required on this proposal. Some anecdotal evidence from a minority of testers, and a brief test on a slow netbook, both suggest that this proposal can make performance worse. I will need to look into this.

[Sam Spilsbury (smspillaz)]

Sure. I'll keep working on testcases for the current stuff we've got and rebase on any other work you come up with when that happens.

[Daniel van Vugt (vanvugt)]

Fixed the slow-motion animations problem in r2900.

[Sam Spilsbury (smspillaz)]

I agree with fixing the plugins for what its worth.

[Sam Spilsbury (smspillaz)]

Hey Daniel,

I had a think about the problem that you were encountering with the plugins. As you said earlier, the plugins are expecting a situation where msSinceLastPaint is going to be reflective of optimalRedrawTime, but with the tickless algorithm, msSinceLastPaint could be quite large. On slower systems, if it took > optimalRedrawTime to actually process a paint, then forcing msSinceLastPaint to be optimalRedrawTime would result in slow animations since frame skipping would not work correctly.

Since the only case we really wanted to cover was the case where the screen went from idle to active, what do you think about doing something like this:

    struct timeval tv;
    int timeDiff;

    gettimeofday (&tv, 0);

    timeDiff = TIMEVALDIFF (&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 > mOptimalRedrawTime && !reschedule)
 timeDiff = mOptimalRedrawTime;

    ...

At least on your branch, reschedule is going to be set every time a plugin requests a redraw in donePaint or addWindowDamage (which is the correct way to do it), so that means that in those cases, msSinceLastPaint is always going to be accurate. And where we have switched from inactive to active, msSinceLastPaint is always going to be mOptimalRedrawTime (in fact, it could be zero, but that might require further testing).

I've updated my changes to reflect this.

[Daniel van Vugt (vanvugt)]

Your suggestion looks incorrect. priv->reschedule is always false there. I don't think it will work.

Best to use my r2900 below. Mine has been tested for a few days, whereas yours would appear to probably not work (or compile in that form :)

[Sam Spilsbury (smspillaz)]

I forgot to mention - the check would have to be moved to before priv->reschedule has been set to false (I've roughly transposed the code from my branch to yours)

[Sam Spilsbury (smspillaz)]

(It works quite well here, and I've tested it with all the plugins)

[Sam Spilsbury (smspillaz)]

I think that checking if the timeDiff is more than 100 only really works around the original problem which I outlined earlier as well. There's a case where some really slow plugin could take more than 100 ms per frame to process some animation, which would result in perceived slowness in its animation code ;-)

[Daniel van Vugt (vanvugt)]

"I forgot to mention - the check would have to be moved to before priv->reschedule has been set to false (I've roughly transposed the code from my branch to yours)"

That still makes no sense in my mind. But if you can reproduce the slow animations bug consistently, and have tested and verified your fix works then go nuts. If however this is another code change you're proposing without actually testing it, then please reconsider.

[Sam Spilsbury (smspillaz)]

On Thu, 22 Dec 2011, Daniel van Vugt wrote:

> "I forgot to mention - the check would have to be moved to before priv->reschedule has been set to false (I've roughly transposed the code from my branch to yours)"
>
> That still makes no sense in my mind. But if you can reproduce the slow animations bug consistently, and have tested and verified your fix works then go nuts. If however this is another code change you're proposing without actually testing it, then please reconsider.

I'm running it right now and haven't run into any problems whatsoever. I
can probably give it a try on some of my other systems as well, but I put
some cases in to force it to run slowly and it still works then.

> --
> https://code.launchpad.net/~vanvugt/compiz-core/fix-880707.2/+merge/83472
> You are requested to review the proposed merge of lp:~vanvugt/compiz-core/fix-880707.2 into lp:compiz-core.
>

[Daniel van Vugt (vanvugt)]

Yep, a simple sleep or something to make painting slow should allow you to reproduce the problem and then verify you're actually fixing it.

In my real-world example, I have an old netbook which takes between 2-4 frames to paint each frame (up to 64ms) during animations. So it's easy to reproduce "slow motion animations" on a machine that only achieves 15-30 FPS.

Oddly enough, as I have mentioned before, this "slow" machine gets a perfect 60 FPS with "Force full screen redraw (buffer swap) on repaint" enabled. But only when using this branch. The difference is staggering.

[lp:~vanvugt/compiz-core/fix-880707.2]

2901. By Daniel van Vugt on 2012-01-12

Merge with upstream changes (lp:compiz-core).

2902. By Daniel van Vugt on 2012-01-16

Merge upstream changes.

2903. By Daniel van Vugt on 2012-01-16

Merge from upstream.

[Sam Spilsbury (smspillaz)]

OK, I think there's been enough discussion here.

I'm confident with the changes this branch is introducing, and think we just need to land it now. I have created an entire testing framework for it, which can be found at lp:~smspillaz/compiz-core/compiz-core.fix_880707.2.test . That test tests for both phase and period timings. On a period of aggressive vblank scheduling for 70 seconds, that test passes each time on my machine.

The testing branch will need to land a little bit after the main one does, once Daniel is ok with it, but ideally it needs to be in before feature freeze.

review: Approve

=== modified file 'plugins/composite/src/privates.h'
--- plugins/composite/src/privates.h	2011-10-15 11:00:51 +0000
+++ plugins/composite/src/privates.h	2012-01-16 10:07:25 +0000
@@ -64,7 +64,7 @@
 
 	void detectRefreshRate ();
 
-	int getTimeToNextRedraw (struct timeval *tv);
+	void scheduleRepaint ();
 
     public:
 
@@ -95,13 +95,9 @@
 	int overlayWindowCount;
 
 	struct timeval lastRedraw;
-	int            nextRedraw;
 	int            redrawTime;
 	int            optimalRedrawTime;
-	int            frameStatus;
-	int            timeMult;
-	bool           idle;
-	int            timeLeft;
+	bool           scheduled, painting, reschedule;
 
 	bool slowAnimations;
 
@@ -110,7 +106,6 @@
 	compiz::composite::PaintHandler *pHnd;
 
 	CompositeFPSLimiterMode FPSLimiterMode;
-	int frameTimeAccumulator;
 
 	CompWindowList withDestroyedWindows;
 };
 
=== modified file 'plugins/composite/src/screen.cpp'
--- plugins/composite/src/screen.cpp	2012-01-12 17:49:40 +0000
+++ plugins/composite/src/screen.cpp	2012-01-16 10:07:25 +0000
@@ -279,17 +279,14 @@
     exposeRects (),
     windowPaintOffset (0, 0),
     overlayWindowCount (0),
-    nextRedraw (0),
     redrawTime (1000 / 50),
     optimalRedrawTime (1000 / 50),
-    frameStatus (0),
-    timeMult (1),
-    idle (true),
-    timeLeft (0),
+    scheduled (false),
+    painting (false),
+    reschedule (false),
     slowAnimations (false),
     pHnd (NULL),
     FPSLimiterMode (CompositeFPSLimiterModeDefault),
-    frameTimeAccumulator (0),
     withDestroyedWindows ()
 {
     gettimeofday (&lastRedraw, 0);
@@ -422,10 +419,6 @@
 
     showOutputWindow ();
 
-    priv->paintTimer.start
-	(boost::bind (&CompositeScreen::handlePaintTimeout, this),
-	 priv->optimalRedrawTime);
-
     return true;
 }
 
@@ -469,11 +462,9 @@
 void
 CompositeScreen::damageScreen ()
 {
-    if (priv->damageMask == 0)
-	priv->paintTimer.setTimes (priv->paintTimer.minLeft ());
-
     priv->damageMask |= COMPOSITE_SCREEN_DAMAGE_ALL_MASK;
     priv->damageMask &= ~COMPOSITE_SCREEN_DAMAGE_REGION_MASK;
+    priv->scheduleRepaint ();
 }
 
 void
@@ -482,9 +473,6 @@
     if (priv->damageMask & COMPOSITE_SCREEN_DAMAGE_ALL_MASK)
 	return;
 
-    if (priv->damageMask == 0)
-	priv->paintTimer.setTimes (priv->paintTimer.minLeft ());
-
     priv->damage += region;
     priv->damageMask |= COMPOSITE_SCREEN_DAMAGE_REGION_MASK;
 
@@ -495,15 +483,14 @@
 
     if (priv->damage.numRects () > 100)
        damageScreen ();
+    priv->scheduleRepaint ();
 }
 
 void
 CompositeScreen::damagePending ()
 {
-    if (priv->damageMask == 0)
-	priv->paintTimer.setTimes (priv->paintTimer.minLeft ());
-
     priv->damageMask |= COMPOSITE_SCREEN_DAMAGE_PENDING_MASK;
+    priv->scheduleRepaint ();
 }
 
 unsigned int
@@ -673,6 +660,7 @@
 	mOptions[CompositeOptions::DetectRefreshRate].value ().set (false);
 	screen->setOptionForPlugin ("composite", "refresh_rate", value);
 	mOptions[CompositeOptions::DetectRefreshRate].value ().set (true);
+	optimalRedrawTime = redrawTime = 1000 / value.i ();
     }
     else
     {
@@ -693,77 +681,47 @@
     priv->FPSLimiterMode = newMode;
 }
 
-int
-PrivateCompositeScreen::getTimeToNextRedraw (struct timeval *tv)
+void
+PrivateCompositeScreen::scheduleRepaint ()
 {
-    int diff;
-
-    diff = compiz::core::timer::timeval_diff (tv, &lastRedraw);
-
-    /* handle clock rollback */
-    if (diff < 0)
-	diff = 0;
-    
-    bool hasVSyncBehavior =
-	(FPSLimiterMode == CompositeFPSLimiterModeVSyncLike ||
-	 (pHnd && pHnd->hasVSync ()));
-
-    if (idle || hasVSyncBehavior)
-    {
-	if (timeMult > 1)
-	{
-	    frameStatus = -1;
-	    redrawTime = optimalRedrawTime;
-	    timeMult--;
-	}
+    if (painting)
+    {
+	reschedule = true;
+	return;
+    }
+
+    if (scheduled)
+	return;
+
+    scheduled = true;
+
+    int delay;
+    if (FPSLimiterMode == CompositeFPSLimiterModeVSyncLike ||
+	(pHnd && pHnd->hasVSync ()))
+    {
+	delay = 1;
     }
     else
     {
-	int next;
-	if (diff > redrawTime)
-	{
-	    if (frameStatus > 0)
-		frameStatus = 0;
-
-	    next = optimalRedrawTime * (timeMult + 1);
-	    if (diff > next)
-	    {
-		frameStatus--;
-		if (frameStatus < -1)
-		{
-		    timeMult++;
-		    redrawTime = diff = next;
-		}
-	    }
-	}
-	else if (diff < redrawTime)
-	{
-	    if (frameStatus < 0)
-		frameStatus = 0;
-
-	    if (timeMult > 1)
-	    {
-		next = optimalRedrawTime * (timeMult - 1);
-		if (diff < next)
-		{
-		    frameStatus++;
-		    if (frameStatus > 4)
-		    {
-			timeMult--;
-			redrawTime = next;
-		    }
-		}
-	    }
-	}
+	struct timeval now;
+	gettimeofday (&now, 0);
+	int elapsed = compiz::core::timer::timeval_diff (&now, &lastRedraw);
+	if (elapsed < 0)
+	    elapsed = 0;
+ 	delay = elapsed < optimalRedrawTime ? optimalRedrawTime - elapsed : 1;
     }
-    
-    if (diff >= redrawTime)
-	return 1;
-
-    if (hasVSyncBehavior)
-	return (redrawTime - diff) * 0.7;
-
-    return redrawTime - diff;
+    /*
+     * Note the use of delay = 1 instead of 0, even though 0 would be better.
+     * A delay of zero is presently broken due to CompTimer bugs;
+     *    1. Infinite loop in CompTimeoutSource::callback when a zero
+     *       timer is set.
+     *    2. Priority set too high in CompTimeoutSource::CompTimeoutSource
+     *       causing the glib main event loop to be starved of X events.
+     * Fixes for both of these issues are being worked on separately.
+     */
+    paintTimer.start
+	(boost::bind (&CompositeScreen::handlePaintTimeout, cScreen),
+	delay);
 }
 
 int
@@ -782,8 +740,9 @@
 CompositeScreen::handlePaintTimeout ()
 {
     struct      timeval tv;
-    int         timeToNextRedraw;
 
+    priv->painting = true;
+    priv->reschedule = false;
     gettimeofday (&tv, 0);
 
     if (priv->damageMask)
@@ -798,21 +757,18 @@
 	/* handle clock rollback */
 	if (timeDiff < 0)
 	    timeDiff = 0;
-
-	if (priv->slowAnimations)
-	{
-	    int msSinceLastPaint;
-
-	    if (priv->FPSLimiterMode == CompositeFPSLimiterModeDisabled)
-		msSinceLastPaint = 1;
-	    else
-		msSinceLastPaint =
-		    priv->idle ? 2 : (timeDiff * 2) / priv->redrawTime;
-
-	    preparePaint (msSinceLastPaint);
-	}
-	else
-	    preparePaint (priv->idle ? priv->redrawTime : timeDiff);
+	/*
+	 * 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 rarely
+	 * larger than the frame rate (optimalRedrawTime).
+	 * So enforce this to keep animations timed correctly and smooth...
+	 */
+	if (timeDiff > 100)
+	    timeDiff = priv->optimalRedrawTime;
+
+	priv->redrawTime = timeDiff;
+	preparePaint (priv->slowAnimations ? 1 : timeDiff);
 
 	/* substract top most overlay window region */
 	if (priv->overlayWindowCount)
@@ -876,39 +832,15 @@
 		break;
 	    }
 	}
-
-	priv->idle = false;
-    }
-    else
-    {
-	priv->idle = true;
     }
 
     priv->lastRedraw = tv;
-    gettimeofday (&tv, 0);
-
-    if (priv->FPSLimiterMode == CompositeFPSLimiterModeDisabled)
-    {
-	const int msToReturn1After = 100;
-
-	priv->frameTimeAccumulator += priv->redrawTime;
-	if (priv->frameTimeAccumulator > msToReturn1After)
-	{
-	    priv->frameTimeAccumulator %= msToReturn1After;
-	    timeToNextRedraw = 1;
-	}
-	else
-	    timeToNextRedraw = 0;
-    }
-    else
-	timeToNextRedraw = priv->getTimeToNextRedraw (&tv);
-
-    if (priv->idle)
-	priv->paintTimer.setTimes (timeToNextRedraw, MAXSHORT);
-    else
-	priv->paintTimer.setTimes (timeToNextRedraw);
-
-    return true;
+    priv->painting = false;
+    priv->scheduled = false;
+    if (priv->reschedule)
+	priv->scheduleRepaint ();
+
+    return false;
 }
 
 void
 
=== modified file 'plugins/opengl/src/screen.cpp'
--- plugins/opengl/src/screen.cpp	2012-01-09 15:12:20 +0000
+++ plugins/opengl/src/screen.cpp	2012-01-16 10:07:25 +0000
@@ -78,6 +78,9 @@
 
     bool canDoSaturated = false;
     bool canDoSlightlySaturated = false;
+
+    unsigned int vsyncCount = 0;
+    unsigned int unthrottledFrames = 0;
 }
 
 CompOutput *targetOutput = NULL;
@@ -1077,15 +1080,29 @@
 void
 waitForVideoSync ()
 {
+    GL::unthrottledFrames++;
     if (GL::waitVideoSync)
     {
 	// Don't wait twice. Just in case.
 	if (GL::swapInterval)
 	    (*GL::swapInterval) (0);
 
+	/*
+	 * While glXSwapBuffers/glXCopySubBufferMESA are meant to do a
+	 * flush before they blit, it is best to not let that happen.
+	 * Because that flush would occur after GL::waitVideoSync, causing
+	 * a delay and the final blit to be slightly out of sync resulting
+	 * in tearing. So we need to do a glFinish before we wait for
+	 * vsync, to absolutely minimize tearing.
+	 */
+	glFinish ();
+
 	// Docs: http://www.opengl.org/registry/specs/SGI/video_sync.txt
-	unsigned int frameno;
-	(*GL::waitVideoSync) (1, 0, &frameno);
+	unsigned int oldCount = GL::vsyncCount;
+	(*GL::waitVideoSync) (1, 0, &GL::vsyncCount);
+
+	if (GL::vsyncCount != oldCount)
+	    GL::unthrottledFrames = 0;
     }
 }
 
@@ -1094,7 +1111,10 @@
 {
     // Docs: http://www.opengl.org/registry/specs/SGI/swap_control.txt
     if (GL::swapInterval)
+    {
 	(*GL::swapInterval) (sync ? 1 : 0);
+	GL::unthrottledFrames++;
+    }
     else if (sync)
 	waitForVideoSync ();
 }
@@ -1177,15 +1197,6 @@
 
     targetOutput = &screen->outputDevs ()[0];
 
-    glFlush ();
-
-    /*
-     * FIXME: Actually fix the composite plugin to be more efficient;
-     * If GL::swapInterval == NULL && GL::waitVideoSync != NULL then the
-     * composite plugin should not be imposing any framerate restriction
-     * (ie. blocking the CPU) at all. Because the framerate will be controlled
-     * and optimized here:
-     */
     if (mask & COMPOSITE_SCREEN_DAMAGE_ALL_MASK)
     {
 	/*
@@ -1257,7 +1268,8 @@
 bool
 PrivateGLScreen::hasVSync ()
 {
-   return (GL::waitVideoSync && optionGetSyncToVblank ());
+    return GL::waitVideoSync && optionGetSyncToVblank () && 
+           GL::unthrottledFrames < 5;
 }
 
 bool