--===============0993199945789370185== Content-Type: multipart/alternative; boundary="===============0358904988095629356==" --===============0358904988095629356== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On Jan. 24, 2012, 7:09 p.m., Martin Gr=C3=A4=C3=9Flin wrote: > > Is this one committed? Nope. Neither the actual swap, nor the nvidia framerate selection. For the latter, i shall have a look on XFree86-VidModeExtension, for the fo= rmer - maybe we can actually move the gl renderer into its own thread if we= rely on Qt4.8 (waiting alongside a mutex for the next sync, when the mutex= is open -> render. Otherwise skip that frame.)? - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103058/#review10051 ----------------------------------------------------------- On Nov. 10, 2011, 4:30 p.m., Thomas L=C3=BCbking wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103058/ > ----------------------------------------------------------- > = > (Updated Nov. 10, 2011, 4:30 p.m.) > = > = > Review request for kwin and Martin Gr=C3=A4=C3=9Flin. > = > = > Description > ------- > = > 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 can= not measure the time for the actual vsync :\ > I set a fuzzyness of 6ms what leads to a majority of 2-3ms times in waits= ync 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 > = > = > Diffs > ----- > = > kwin/composite.cpp aa721b8 = > kwin/options.cpp 19c3ee5 = > kwin/scene.h d8bcf48 = > kwin/scene.cpp 413e46f = > kwin/scene_basic.h a087eb5 = > kwin/scene_basic.cpp cc8dbdd = > kwin/scene_opengl.h e13d8a5 = > kwin/scene_opengl.cpp 47015b3 = > kwin/scene_opengl_egl.cpp 22e082c = > kwin/scene_opengl_glx.cpp ddebcd0 = > kwin/scene_xrender.h 6c916c8 = > kwin/scene_xrender.cpp 3618d79 = > kwin/workspace.h 4d7fda5 = > kwin/workspace.cpp 6a8e2df = > = > Diff: http://git.reviewboard.kde.org/r/103058/diff/diff > = > = > Testing > ------- > = > I've used a CRT for testing which can sync every 11ms ie. 85Hz and lowere= d the maxFPS down to 10fps with pretty constant results for the time lost w= aiting for the sync. > = > = > Thanks, > = > Thomas L=C3=BCbking > = > --===============0358904988095629356== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/103058/

On January 24th, 2012, 7:09 p.m., Martin Gr= =C3=A4=C3=9Flin wrote:
Is this o=
ne committed?

Nope. Neith=
er the actual swap, nor the nvidia framerate selection.
For the latter, i shall have a look on XFree86-VidModeExtension, for the fo=
rmer - maybe we can actually move the gl renderer into its own thread if we=
 rely on Qt4.8 (waiting alongside a mutex for the next sync, when the mutex=
 is open -> render. Otherwise skip that frame.)?

- Thomas

On November 10th, 2011, 4:30 p.m., Thomas L=C3=BCbking wrote:

Review request for kwin and Martin Gr=C3=A4=C3=9Flin.

By Thomas L=C3=BCbking.

Updated Nov. 10, 2011, 4:30 p.m.

Descripti= on

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

There's some debug code to print lagging.

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

Testing <= /h1>

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 fo=
r the time lost waiting for the sync.

Diffs=

kwin/composite.cpp (aa721b8)
kwin/options.cpp (19c3ee5)
kwin/scene.h (d8bcf48)
kwin/scene.cpp (413e46f)
kwin/scene_basic.h (a087eb5)
kwin/scene_basic.cpp (cc8dbdd)
kwin/scene_opengl.h (e13d8a5)
kwin/scene_opengl.cpp (47015b3)
kwin/scene_opengl_egl.cpp (22e082c)=
kwin/scene_opengl_glx.cpp (ddebcd0)=
kwin/scene_xrender.h (6c916c8)
kwin/scene_xrender.cpp (3618d79)
kwin/workspace.h (4d7fda5)
kwin/workspace.cpp (6a8e2df)

--===============0358904988095629356==-- --===============0993199945789370185== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kwin mailing list kwin@kde.org https://mail.kde.org/mailman/listinfo/kwin --===============0993199945789370185==--