[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-12 13:25:24
Message-ID: 20110812132524.3128.23104 () 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/102311/
-----------------------------------------------------------

(Updated Aug. 12, 2011, 1:25 p.m.)


Review request for kwin and Martin Gräßlin.


Changes
-------

- really fix bug #160393 (hopefully). apparently was just a value init thing. \
readyForPainting broke bug and works until ready_for_painting is set true when \
managing while not compositing) => no more stupid flicker when showing eg. qss styled \
Qt windows

- add safety timer for the rync request (1s when showing up - triggers immediate \
repaint, 10s when resizing. XSYNC is assumed to be broken in the latter case and \
completely disabled)

- drop damage events while "syncRequest.isPending". we add a full damage when \
performing the resize. removes flicker resp. "preaction" (gtk3 resizes the client \
significantly before sending the sync response - esp. notable when shrinking \
gtk3-demo with the first version)

- drop redundant XMoveResize when isResize && syncRequest.counter (has happened \
before sending the request)

- code cleanup: moved sync related stuff into a struct and picked saner member names

TODO: compile w/o XSYNC support since the preproc conditions are certainly not \
complete... :-(


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 (updated)
-----

  kwin/client.h 93510ec 
  kwin/client.cpp 46c8eff 
  kwin/composite.cpp d2c31c0 
  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 />


<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. 12, 2011, 1:25 p.m.</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;">- really fix bug #160393 (hopefully). apparently was just a value init \
thing. readyForPainting broke bug and works until ready_for_painting is set true when \
managing while not compositing) =&gt; no more stupid flicker when showing eg. qss \
styled Qt windows

- add safety timer for the rync request (1s when showing up - triggers immediate \
repaint, 10s when resizing. XSYNC is assumed to be broken in the latter case and \
completely disabled)

- drop damage events while &quot;syncRequest.isPending&quot;. we add a full damage \
when performing the resize. removes flicker resp. &quot;preaction&quot; (gtk3 resizes \
the client significantly before sending the sync response - esp. notable when \
shrinking gtk3-demo with the first version)

- drop redundant XMoveResize when isResize &amp;&amp; syncRequest.counter (has \
happened before sending the request)

- code cleanup: moved sync related stuff into a struct and picked saner member names

TODO: compile w/o XSYNC support since the preproc conditions are certainly not \
complete... :-(</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;">&lt;assume some very angry rant about the &quot;protocol&quot;, it&#39;s \
authors and the author of the original patch here&gt;

I finally got along, looking depper into this.
So far, the kwin implementation did hardly more than wasting resources.

=&gt; changes:
a) ensure to NEVER send a second sync request while one&#39;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&#39;s a \
pending sync (the client&#39;s not done anyway and we cannot send a sync request) d) \
move the *request* from &quot;performMoveResize&quot; into handleMoveResize, replace \
&quot;syncTimeout&quot; (great name) with &quot;performMoveResize&quot; and have it \
do exactly that. e) don&#39;t new QTimer; delete QTimer with every size change - \
it&#39;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 &quot;oh, blast. crashed.&quot; g) fix tileset \
#ifdef (the geometry _has_ to be set esp. if there&#39;s no tiling at all)

==&gt; todo:
- I thought about using the compositor to perform a texture scale while we&#39;re \
waiting for the client (but the client/effectwindow would have to keep \
                &quot;realGeometry&quot; vs. &quot;visualGeometry&quot; 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: &quot;don&#39;t use xsync protocol&quot; - frankly, this thing is \
so much wonky by design that i&#39;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&#39;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&#39;d like to have this in master as soon as possible (also before \
&quot;playing around&quot; 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> \
(updated)</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">(d2c31c0)</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