[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Review Request: Improve/fix vsync usage, paintcycling
From: Martin_Gräßlin <kde () martin-graesslin ! com>
Date: 2010-12-18 16:32:26
Message-ID: 20101218163226.13970.94138 () vidsolbach ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6120/#review9304
-----------------------------------------------------------
Ship it!
Did the ultimative test today: one hour of fullscreen full hd video with co=
mpositing enabled. Could not notice any tearing
- Martin
On 2010-12-15 22:12:41, Thomas L=C3=BCbking wrote:
> =
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6120/
> -----------------------------------------------------------
> =
> (Updated 2010-12-15 22:12:41)
> =
> =
> Review request for kwin and Martin Gr=C3=A4=C3=9Flin.
> =
> =
> Summary
> -------
> =
> - Replace signal/slot by timerEvent:
> nobrainer - signal/slot has a CPU overhead and at least one event cycle d=
elay
> =
> - General change in the vblank strategy + fix sync bug:
> The present implementation has a bug which causes an (unintended) repaint=
at max 1ms delay. This is fixed.
> Also kwin now tries to avoid calling glXWaitVideoSync, because it blocks =
and -while costs nothing- steals the cpu time from other operations (notice=
that currently kwin tries to slot 10ms ahead of the next estimated sync, s=
ince painting usually takes up two 2ms that means we're loosing 8ms from a =
16ms timeframe (60Hz, integer division...), because of the bug, you'll actu=
ally wait 14-15 ms...) by just waiting for the screen.
> The present estimation isn't perfect and could be improved by bitshifting=
up the interval for more precision. Nevertheless you get hardly any tearin=
g this way.
> =
> - Introduction of com_maxfps... err... "MaxFPS"
> I took the opportunity to separate the target refreshrate from the screen=
vblank interval since there's no point in updating the content up to 100Hz=
(doesn't happen? play 3 videos at once and have a little bad luck - X11 is=
n'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=
the proper time amount for the vblank, so there is no "tearing with vsync =
& nvidia" - but this one...)
> It's very present if you play a video (eg. 23.976Hz) with mplayer which p=
rints to konsole at about 50Hz (...) and have the (tear prone) video inters=
ecting and above the mplayer output.
> =
> You'll see "tearing blocks" in the high frequent konsole area of the vide=
o window.
> From what i can say this seems to be caused by the texture bound to the v=
ideo being updated "immediately" and ahead of the damageNotify event and ge=
ts painted in "dirty" with the konsole update.
> =
> I've tried to compensate this by marking the actual "dirty" area in paint=
SimpleScreen but that oc. doesn't work for translucent windows (and caused =
much more region calculations - huh)
> =
> For the moment this could be worked around by simply raising MaxFPS (ie. =
get closer to the current behaviour) but it would be better to prevent this=
in the first place and have the damage area match the actual texture updat=
e.
> =
> =
> Diffs
> -----
> =
> /trunk/KDE/kdebase/workspace/kwin/composite.cpp 1206723 =
> /trunk/KDE/kdebase/workspace/kwin/options.h 1206723 =
> /trunk/KDE/kdebase/workspace/kwin/options.cpp 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 =
> =
> Diff: http://svn.reviewboard.kde.org/r/6120/diff
> =
> =
> Testing
> -------
> =
> =
> Thanks,
> =
> Thomas
> =
>
[Attachment #5 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://svn.reviewboard.kde.org/r/6120/">http://svn.reviewboard.kde.org/r/6120/</a>
</td>
</tr>
</table>
<br />
<p>Ship it!</p>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Did the ultimative test \
today: one hour of fullscreen full hd video with compositing enabled. Could not \
notice any tearing</pre> <br />
<p>- Martin</p>
<br />
<p>On December 15th, 2010, 10:12 p.m., Thomas Lübking wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://svn.reviewboard.kde.orgrb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for kwin and Martin Gräßlin.</div>
<div>By Thomas Lübking.</div>
<p style="color: grey;"><i>Updated 2010-12-15 22:12:41</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">- Replace signal/slot by timerEvent: nobrainer - signal/slot has a CPU \
overhead and at least one event cycle delay
- General change in the vblank strategy + fix sync bug:
The present implementation has a bug which causes an (unintended) repaint at max 1ms \
delay. This is fixed. Also kwin now tries to avoid calling glXWaitVideoSync, because \
it blocks and -while costs nothing- steals the cpu time from other operations (notice \
that currently kwin tries to slot 10ms ahead of the next estimated sync, since \
painting usually takes up two 2ms that means we're loosing 8ms from a 16ms \
timeframe (60Hz, integer division...), because of the bug, you'll actually wait \
14-15 ms...) by just waiting for the screen. The present estimation isn't perfect \
and could be improved by bitshifting up the interval for more precision. Nevertheless \
you get hardly any tearing this way.
- Introduction of com_maxfps... err... "MaxFPS"
I took the opportunity to separate the target refreshrate from the screen vblank \
interval since there's no point in updating the content up to 100Hz (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 the proper time \
amount for the vblank, so there is no "tearing with vsync & 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 \
intersecting 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 video being \
> updated "immediately" and ahead of the damageNotify event and gets \
> painted in "dirty" with the konsole update.
I've tried to compensate this by marking the actual "dirty" area in \
paintSimpleScreen but that oc. doesn't work for translucent windows (and caused \
much more region calculations - huh)
For the moment this could be worked around by simply raising MaxFPS (ie. get closer \
to the current behaviour) but it would be better to prevent this in the first place \
and have the damage area match the actual texture update. </pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/trunk/KDE/kdebase/workspace/kwin/composite.cpp <span style="color: \
grey">(1206723)</span></li>
<li>/trunk/KDE/kdebase/workspace/kwin/options.h <span style="color: \
grey">(1206723)</span></li>
<li>/trunk/KDE/kdebase/workspace/kwin/options.cpp <span style="color: \
grey">(1206723)</span></li>
<li>/trunk/KDE/kdebase/workspace/kwin/scene_opengl.h <span style="color: \
grey">(1206723)</span></li>
<li>/trunk/KDE/kdebase/workspace/kwin/scene_opengl.cpp <span style="color: \
grey">(1206723)</span></li>
<li>/trunk/KDE/kdebase/workspace/kwin/workspace.h <span style="color: \
grey">(1206723)</span></li>
<li>/trunk/KDE/kdebase/workspace/kwin/workspace.cpp <span style="color: \
grey">(1206723)</span></li>
</ul>
<p><a href="http://svn.reviewboard.kde.org/r/6120/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic