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).
I've now tested both theories with actual code changes;
- if (timeDiff > 100) drawTime && !priv->reschedule) drawTime;
+ if (timeDiff > priv->optimalRe
timeDiff = priv->optimalRe
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).