On May 3rd, 2012, 8:46 a.m., Martin Gräßlin wrote:

kwin/scene.cpp (Diff revision 7)
void Scene::paintScreen(int* mask, QRegion* region)
		162	#define LIE_ABOUT_TIME_DIFF 1
163	if (!last_time.isValid()) {	163	if (!last_time.isValid()) {
164	// Painting has been idle (optimized out) for some time,	164	// Painting has been idle (optimized out) for some time,
165	// which means time_diff would be huge and would break animations.	165	// which means time_diff would be huge and would break animations.
166	// Simply set it to one (zero would mean no change at all and could	166	// Simply set it to one (zero would mean no change at all and could
167	// cause problems).	167	// cause problems).
168	time_diff = 1;	168	time_diff = 1;
169	last_time.start();	169	last_time.start();
170	} else	170	} else
		171	#if LIE_ABOUT_TIME_DIFF
		172	time_diff = last_time.restart() + wspace->nextFrameDelay();
		173	#else
171	time_diff = last_time.restart();	174	time_diff = last_time.restart();
		175	#endif
172		176
173	if (time_diff < 0) // check time rollback	177	if (time_diff < 0) // check time rollback
174	time_diff = 1;	178	time_diff = 1;
		179	#undef LIE_ABOUT_TIME_DIFF

why this define?

I think I raised the option to do this and we never defined whether to do or not, so i just added both variants.
The way it is we lie about the time which has actually passed to compensate the lagging frame (what makes the animation shorter but fix the time regarding the triggering event)

You can just pick one or i'll remove the dead branch before committing (and add a comment that we lie)

On May 3rd, 2012, 8:46 a.m., Martin Gräßlin wrote:

kwin/scene_opengl_egl.cpp (Diff revision 7)
SceneOpenGL::SceneOpenGL(Workspace* ws)
		63	#if 0
		64	// "theoretically".
		65	// - internet rumors say: it doesn't work with TBDR
		66	// - eglSwapInterval has no impact on intel GMA chips
		67	has_waitSync = options->glVSync;
		68	if (has_waitSync) {
		69	has_waitSync = (eglSwapInterval( dpy, 1) == EGL_TRUE);
		70	if (!has_waitSync)
		71	kWarning(1212) << "Could not activate EGL v'sync on this system";
		72	}
		73	if (!has_waitSync)
		74	eglSwapInterval( dpy, 0); // deactivate syncing
		75	#else
		76	has_waitSync = false;
		77	#endif

should it go in?

I'll try on gles syncing tonight - drivers got eventually updated but according to fredrik this should actually be just forced on by all mesa drivers.
TBDR however can likely really not sync for principal reasons - do you have a PowerVR on some board?

On May 3rd, 2012, 8:46 a.m., Martin Gräßlin wrote:

kwin/scene_opengl_glx.cpp (Diff revision 7)
SceneOpenGL::SceneOpenGL(Workspace* ws)
		84	#if 0
		85	if (glXSwapInterval(0) == 0) // no good - mesa/dri return an invalid rage error
83	has_waitSync = true;	86	has_waitSync = true;
84	else	87	else
		88	qWarning() << "NO VSYNC! glXSwapInterval failed" << glXWaitVideoSync(1, 0, &sync);
		89	#else
		90	// instead just try to deactivate - mesa/dri/intel will likely throw an error, though
		91	has_waitSync = true;
		92	glXSwapInterval(0);
		93	#endif

what about this ifdef'ed code?

The commented check is actually "correct" by when i tried only nvidia but not intel passed it. Latter yelled and "rage" (that reads" "out of range" - i'm really good at typos ;-) error - what is wrong. The command would deactivate the swapinterval (syncing glXSwapBuffers calls) but as mentioned according to fredrik and iirc, that's forced on anyway (got to re-investigate)

It however doesn't have *that* much of an impact since glXSwapBuffers isn't the default action anyway (on glx)

I'd similarly add a comment about what should happen and why we don't check instead of the branch

- Thomas

On April 21st, 2012, 6:11 p.m., Thomas Lübking wrote:

This performs a paint & glFlush immediately after the buffer swapping and defers the next swapping to the next anticipated frame (or idling)
The behavior is still not as deterministic as we hoped to be since we cannot measure the time for the actual vsync :\
I set a fuzzyness of 6ms what leads to a majority of 2-3ms times in waitsync but single wait times up to 8 or 9ms occur (what ultimately can be part of the syncing itself)

There's some debug code to print lagging.

TODO:
- attempt egl support
- probably lie to the effects about the time

I've used a CRT for testing which can sync every 11ms ie. 85Hz and lowered the maxFPS down to 10fps with pretty constant results for the time lost waiting for the sync.