This is an automatically generated e-mail. To reply, visit: http://svn.reviewb= oard.kde.org/r/6120/

Ship it!

Did the ul=
timative test today: one hour of fullscreen full hd video with compositing =
enabled. Could not notice any tearing

- Martin

On December 15th, 2010, 10:12 p.m., Thomas L=C3=BCbking wrote:

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

By Thomas L=C3=BCbking.

Updated 2010-12-15 22:12:41

Descripti= on

- Replace signal/slot by timerEvent:
nobrainer - signal/slot has a CPU overhead and at least one event cycle del=
ay

- General change in the vblank strategy + fix sync bug:
The present implementation has a bug which causes an (unintended) repaint a=
t max 1ms delay. This is fixed.
Also kwin now tries to avoid calling glXWaitVideoSync, because it blocks an=
d -while costs nothing- steals the cpu time from other operations (notice t=
hat currently kwin tries to slot 10ms ahead of the next estimated sync, sin=
ce painting usually takes up two 2ms that means we're loosing 8ms from =
a 16ms timeframe (60Hz, integer division...), because of the bug, you'l=
l actually wait 14-15 ms...) by just waiting for the screen.
The present estimation isn't perfect and could be improved by bitshifti=
ng up the interval for more precision. Nevertheless you get hardly any tear=
ing this way.

- Introduction of com_maxfps... err... "MaxFPS"
I took the opportunity to separate the target refreshrate from the screen v=
blank interval since there's no point in updating the content up to 100=
Hz (doesn't happen? play 3 videos at once and have a little bad luck - =
X11 isn't synced ;-) just because your screen can do.
It defaults to "35Hz" what i consider a sane value for a Desktop =
(it's no shooter...),

- BUT (remaining issue)
This exposed a general problem with compositing which i first thought to be=
 tearing (from tests with two glXWaitVideoSync calls, my nvidia GPU waits t=
he proper time amount for the vblank, so there is no "tearing with vsy=
nc & nvidia" - but this one...)
It's very present if you play a video (eg. 23.976Hz) with mplayer which=
 prints to konsole at about 50Hz (...) and have the (tear prone) video inte=
rsecting and above the mplayer output.

You'll see "tearing blocks" in the high frequent konsole area=
 of the video window.
>From what i can say this seems to be caused by the texture bound to the vid=
eo being updated "immediately" and ahead of the damageNotify even=
t and gets painted in "dirty" with the konsole update.

I've tried to compensate this by marking the actual "dirty" a=
rea in paintSimpleScreen but that oc. doesn't work for translucent wind=
ows (and caused much more region calculations - huh)

For the moment this could be worked around by simply raising MaxFPS (ie. ge=
t closer to the current behaviour) but it would be better to prevent this i=
n the first place and have the damage area match the actual texture update.

Diffs=

/trunk/KDE/kdebase/workspace/kwin/composite.cpp (1206723)
/trunk/KDE/kdebase/workspace/kwin/options.h (1206723)
/trunk/KDE/kdebase/workspace/kwin/scene_opengl.h (1206723)
/trunk/KDE/kdebase/workspace/kwin/scene_opengl.cpp (1206723)
/trunk/KDE/kdebase/workspace/kwin/workspace.h (1206723)
/trunk/KDE/kdebase/workspace/kwin/workspace.cpp (1206723)

View Diff