[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Review Request: Finally really fix the XSYNC implementation
From: Thomas_Lübking <thomas.luebking () web ! de>
Date: 2011-08-23 23:41:50
Message-ID: 20110823234150.13227.99232 () vidsolbach ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Aug. 23, 2011, 6:41 p.m., Martin Gräßlin wrote:
> > very nice :-) Just see the two minor comments below.
> >
> > Do you know whether GTK applications implement sync properly? All GTK \
> > apps I just tried (Firefox (yeah not the best example), GIMP and \
> > Inkscape) were still very jumpy compared to the Qt applications.
No idea whether they implement it "correctly" but they do need the sync \
request _before_ the XMoveResize while Qt doesn't seem to care (XSync? \
Implementation?)
I wasn't sure what's the "correct" order (isn't specified)
My understanding of a "sync request" was and is: align to the current state \
and yell when you're out of work It's however (on gtk+ at least) rather: "i \
set a mutex, fire a bunch of instructions (probably only "next \
XMoveResize") and you remove the mutex when you're done"
Whatever. Swapping the two lines will prevent gtk+ applications to rely on \
the timeout and Qt ones won't break. *sigh*
Swapped, fixed commented parts and pushed.
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102311/#review5949
-----------------------------------------------------------
On Aug. 14, 2011, 9:08 a.m., Thomas Lübking wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102311/
> -----------------------------------------------------------
>
> (Updated Aug. 14, 2011, 9:08 a.m.)
>
>
> Review request for kwin and Martin Gräßlin.
>
>
> Summary
> -------
>
> <assume some very angry rant about the "protocol", it's authors and the \
> author of the original patch here>
> I finally got along, looking depper into this.
> So far, the kwin implementation did hardly more than wasting resources.
>
> => changes:
> a) ensure to NEVER send a second sync request while one's still pending \
> (leading to the issues back then) b) trigger a resize of the targetted \
> geometry before requesting the sync (so the client actually syncs to the \
> proper size and is there when we release the mutex) c) skip all \
> moveResizeHandle calls while there's a pending sync (the client's not \
> done anyway and we cannot send a sync request) d) move the *request* from \
> "performMoveResize" into handleMoveResize, replace "syncTimeout" (great \
> name) with "performMoveResize" and have it do exactly that. e) don't new \
> QTimer; delete QTimer with every size change - it's on the heap.... f) \
> reduce the timeout to 250ms. waiting 500ms for the client is _completely_ \
> inacceptable. if it cannot keep pace: bad luck. but having the user to \
> wait half a second makes him feel "oh, blast. crashed." g) fix tileset \
> #ifdef (the geometry _has_ to be set esp. if there's no tiling at all)
> ==> todo:
> - I thought about using the compositor to perform a texture scale while \
> we're waiting for the client (but the client/effectwindow would have to \
> keep "realGeometry" vs. "visualGeometry" for this
> - look around whether XSYNC preproc checks are sufficient
> - attempt to drop the second XMoveResize call for the window() WId (since \
> it happened with the sync request)
> - add a checkbox: "don't use xsync protocol" - frankly, this thing is so \
> much wonky by design that i'd nearly say to remove support completely.
> For the records (maybe i should add a comment in the code?)
> - two sync requests on the stack will break it. no way to re-sync.
> - one should aparently trigger the client resize before starting the sync \
> request. otherwise the entire thing is pointless.
> - sending the configure notifications is important. don't ask me why, but \
> w/o the client will stop sending sync events just like in the above case
>
> This addresses bug 160393.
> http://bugs.kde.org/show_bug.cgi?id=160393
>
>
> Diffs
> -----
>
> kwin/client.h 93510ec
> kwin/client.cpp 46c8eff
> kwin/composite.cpp edffac1
> kwin/events.cpp f523bf7
> kwin/geometry.cpp 51ed034
> kwin/manage.cpp 47c8814
>
> Diff: http://git.reviewboard.kde.org/r/102311/diff
>
>
> Testing
> -------
>
> yes.
> no more white edges in konsole (but for timeouts).
> no issues with clemens qclock testcase (which blocks painting for some \
> hundred ms) - scaling is smooth, blocks (as expected) and smoothly \
> continues afterwards.
> nevertheless, i'd like to have this in master as soon as possible (also \
> before "playing around" for performance locally) and hopefully a lot of \
> 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://git.reviewboard.kde.org/r/102311/">http://git.reviewboard.kde.org/r/102311/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; \
padding-left: 10px;"> <p style="margin-top: 0;">On August 23rd, 2011, 6:41 \
p.m., <b>Martin Gräßlin</b> wrote:</p> <blockquote style="margin-left: \
1em; border-left: 2px solid #d0d0d0; padding-left: 10px;"> <pre \
style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">very nice :-) \
Just see the two minor comments below.
Do you know whether GTK applications implement sync properly? All GTK apps \
I just tried (Firefox (yeah not the best example), GIMP and Inkscape) were \
still very jumpy compared to the Qt applications.</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">No idea \
whether they implement it "correctly" but they do need the sync \
request _before_ the XMoveResize while Qt doesn't seem to care (XSync? \
Implementation?)
I wasn't sure what's the "correct" order (isn't \
specified) My understanding of a "sync request" was and is: align \
to the current state and yell when you're out of work It's however \
(on gtk+ at least) rather: "i set a mutex, fire a bunch of \
instructions (probably only "next XMoveResize") and you remove \
the mutex when you're done"
Whatever. Swapping the two lines will prevent gtk+ applications to rely on \
the timeout and Qt ones won't break. *sigh*
Swapped, fixed commented parts and pushed.</pre>
<br />
<p>- Thomas</p>
<br />
<p>On August 14th, 2011, 9:08 a.m., Thomas Lübking 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 and Martin Gräßlin.</div>
<div>By Thomas Lübking.</div>
<p style="color: grey;"><i>Updated Aug. 14, 2011, 9:08 a.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;"><assume some very angry rant about the \
"protocol", it's authors and the author of the original patch \
here>
I finally got along, looking depper into this.
So far, the kwin implementation did hardly more than wasting resources.
=> changes:
a) ensure to NEVER send a second sync request while one's still pending \
(leading to the issues back then) b) trigger a resize of the targetted \
geometry before requesting the sync (so the client actually syncs to the \
proper size and is there when we release the mutex) c) skip all \
moveResizeHandle calls while there's a pending sync (the client's \
not done anyway and we cannot send a sync request) d) move the *request* \
from "performMoveResize" into handleMoveResize, replace \
"syncTimeout" (great name) with "performMoveResize" and \
have it do exactly that. e) don't new QTimer; delete QTimer with every \
size change - it's on the heap.... f) reduce the timeout to 250ms. \
waiting 500ms for the client is _completely_ inacceptable. if it cannot \
keep pace: bad luck. but having the user to wait half a second makes him \
feel "oh, blast. crashed." g) fix tileset #ifdef (the geometry \
_has_ to be set esp. if there's no tiling at all)
==> todo:
- I thought about using the compositor to perform a texture scale while \
we're waiting for the client (but the client/effectwindow would have to \
keep "realGeometry" vs. \
"visualGeometry" for this
- look around whether XSYNC preproc checks are sufficient
- attempt to drop the second XMoveResize call for the window() WId (since \
it happened with the sync request)
- add a checkbox: "don't use xsync protocol" - frankly, this \
thing is so much wonky by design that i'd nearly say to remove support \
completely.
For the records (maybe i should add a comment in the code?)
- two sync requests on the stack will break it. no way to re-sync.
- one should aparently trigger the client resize before starting the sync \
request. otherwise the entire thing is pointless.
- sending the configure notifications is important. don't ask me why, \
but w/o the client will stop sending sync events just like in the above \
case</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;">yes. no more white edges in konsole (but for timeouts).
no issues with clemens qclock testcase (which blocks painting for some \
hundred ms) - scaling is smooth, blocks (as expected) and smoothly \
continues afterwards.
nevertheless, i'd like to have this in master as soon as possible (also \
before "playing around" for performance locally) and hopefully a \
lot of testing...</pre> </td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="http://bugs.kde.org/show_bug.cgi?id=160393">160393</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> \
</h1> <ul style="margin-left: 3em; padding-left: 0;">
<li>kwin/client.h <span style="color: grey">(93510ec)</span></li>
<li>kwin/client.cpp <span style="color: grey">(46c8eff)</span></li>
<li>kwin/composite.cpp <span style="color: grey">(edffac1)</span></li>
<li>kwin/events.cpp <span style="color: grey">(f523bf7)</span></li>
<li>kwin/geometry.cpp <span style="color: grey">(51ed034)</span></li>
<li>kwin/manage.cpp <span style="color: grey">(47c8814)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/102311/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