[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Review Request: [RFC] Move decoration painting out of
From: "Philipp Knechtges" <philipp-dev () knechtges ! com>
Date: 2011-09-15 8:16:58
Message-ID: 20110915081658.22780.73291 () vidsolbach ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102614/#review6528
-----------------------------------------------------------
The graphical glitches with the new version of paintSimpleScreen were actua=
lly the reason why i dropped the paintPending timer in 867f825a386aa09b255d=
85bcce038dd32f368d63.
The problem is that the compositeTimer can be first and the paintPending ti=
mer can be second in the queue, such that paintSimpleScreen paints the old =
version of the decoration and the updated one doesn't get painted because t=
he damage has already been cleared. So the glitches normally disappear afte=
r a repaint.
- Philipp
On Sept. 14, 2011, 6:26 p.m., Martin Gr=C3=A4=C3=9Flin wrote:
> =
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102614/
> -----------------------------------------------------------
> =
> (Updated Sept. 14, 2011, 6:26 p.m.)
> =
> =
> Review request for kwin.
> =
> =
> Summary
> -------
> =
> When doing the callgrind analysis I noticed that the call to paint the de=
corations is really expensive (which we already knew due to lag in present =
windows when switching and so on). My idea to tackle this problem is to mov=
e the ensurePainted out of performPaint using Arthur's DecorationPaintRedir=
ector.
> =
> This first diff is just a request for comments as I want to know whether =
this could cause some problems. When the decoration is damaged it uses a 0 =
msec singleshot timer to move the painting into the next event loop (to pre=
vent the false detection of recursive painting) and on timeout the ensurePa=
inted is triggered.
> =
> The result is: before the inclusive costs of Window::performPaint() was 2=
5 % (1400 calls) with 18 % on ensurePainted with just 69 (!) calls. After t=
he inclusive costs of Window::performPaint() is only ~ 12 % (2100 calls). E=
nsurePainted has still a high cost but is moved out of the hot path.
> =
> =
> Diffs
> -----
> =
> kwin/decorationpaintredirector.h PRE-CREATION =
> kwin/decorationpaintredirector.cpp PRE-CREATION =
> kwin/scene_opengl.cpp 47015b3 =
> =
> Diff: http://git.reviewboard.kde.org/r/102614/diff
> =
> =
> Testing
> -------
> =
> With NVIDIA I had seen some rendering artefacts when switching windows. I=
will watch how it behaves with radeon (could be our well known NVIDIA suck=
s with pixmap problem).
> =
> Ok there is also a problem with radeon and decoration not being updated c=
orrectly - need to investigate.
> =
> =
> Thanks,
> =
> Martin
> =
>
[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://git.reviewboard.kde.org/r/102614/">http://git.reviewboard.kde.org/r/102614/</a>
</td>
</tr>
</table>
<br />
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The graphical glitches \
with the new version of paintSimpleScreen were actually the reason why i dropped the \
paintPending timer in 867f825a386aa09b255d85bcce038dd32f368d63. The problem is that \
the compositeTimer can be first and the paintPending timer can be second in the \
queue, such that paintSimpleScreen paints the old version of the decoration and the \
updated one doesn't get painted because the damage has already been cleared. So \
the glitches normally disappear after a repaint.</pre> <br />
<p>- Philipp</p>
<br />
<p>On September 14th, 2011, 6:26 p.m., Martin Gräßlin wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://git.reviewboard.kde.org/media/rb/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.</div>
<div>By Martin Gräßlin.</div>
<p style="color: grey;"><i>Updated Sept. 14, 2011, 6:26 p.m.</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;">When doing the callgrind analysis I noticed that the call to paint the \
decorations is really expensive (which we already knew due to lag in present windows \
when switching and so on). My idea to tackle this problem is to move the \
ensurePainted out of performPaint using Arthur's DecorationPaintRedirector.
This first diff is just a request for comments as I want to know whether this could \
cause some problems. When the decoration is damaged it uses a 0 msec singleshot timer \
to move the painting into the next event loop (to prevent the false detection of \
recursive painting) and on timeout the ensurePainted is triggered.
The result is: before the inclusive costs of Window::performPaint() was 25 % (1400 \
calls) with 18 % on ensurePainted with just 69 (!) calls. After the inclusive costs \
of Window::performPaint() is only ~ 12 % (2100 calls). EnsurePainted has still a high \
cost but is moved out of the hot path.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </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;">With NVIDIA I had seen some rendering artefacts when switching windows. \
I will watch how it behaves with radeon (could be our well known NVIDIA sucks with \
pixmap problem).
Ok there is also a problem with radeon and decoration not being updated correctly - \
need to investigate.</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>kwin/decorationpaintredirector.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>kwin/decorationpaintredirector.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>kwin/scene_opengl.cpp <span style="color: grey">(47015b3)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/102614/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