[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Review Request: Improve/fix vsync usage, paintcycling
From: Thomas_Lübking <thomas.luebking () gmail ! com>
Date: 2010-12-15 22:12:41
Message-ID: 20101215221241.27744.77661 () 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/
-----------------------------------------------------------
(Updated 2010-12-15 22:12:41.238813)
Review request for kwin and Martin Gr=C3=A4=C3=9Flin.
Changes
-------
revert my personal toolwindow timer inc from another patch, sorry...
Summary
-------
- 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 16=
ms timeframe (60Hz, integer division...), because of the bug, you'll actual=
ly wait 14-15 ms...) by just waiting for the screen.
The present estimation isn't perfect and could be improved by bitshifting u=
p 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 v=
blank 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 s=
hooter...),
- 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 vsync & =
nvidia" - but this one...)
It's very present if you play a video (eg. 23.976Hz) with mplayer which pri=
nts to konsole at about 50Hz (...) and have the (tear prone) video intersec=
ting 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 event and gets=
painted in "dirty" with the konsole update.
I've tried to compensate this by marking the actual "dirty" area in paintSi=
mpleScreen but that oc. doesn't work for translucent windows (and caused mu=
ch 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 (updated)
-----
/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 />
<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.238813</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Changes</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;">revert my personal toolwindow timer inc from another patch, \
sorry...</pre> </td>
</tr>
</table>
<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> \
(updated)</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