[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Review Request 115297: Keep KWin responsive while loading all effects
From: Thomas_Lübking <thomas.luebking () gmail ! com>
Date: 2014-01-26 15:19:36
Message-ID: 20140126151936.17576.82047 () probe ! kde ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Jan. 24, 2014, 3:51 p.m., Thomas Lübking wrote:
> > kwin/effects.cpp, line 198
> > <https://git.reviewboard.kde.org/r/115297/diff/1/?file=240441#file240441line198>
> >
> > if (!m_dequeueIsScheduled) {
> > m_dequeueIsScheduled = true;
> > QMetaObject::invokeMethod(this, "dequeue", Qt::QueuedConnection);
> > }
> >
> > does not abuse QTimer and allows for passing parameters to dequeue (if ever \
> > required)
>
> Martin Gräßlin wrote:
> I knew you would suggest that :-) Is the behavior really exactly the same? Given \
> the documentation I'm unsure about it. For invokeMethod we have: "If type is \
> Qt::QueuedConnection, a QEvent will be sent and the member is invoked as soon as \
> the application enters the main event loop."
> For QTimer with 0 msec we have:
> "A QTimer with a timeout interval of 0 will time out as soon as all the events in \
> the window system's event queue have been processed."
> Given the documentation I understand that invokeMethod will be first in the event \
> loop, but the QTimer will be last in the event loop. I might be wrong about that \
> and they both behave the same, but in case it's really that difference I want to \
> have the QTimer behavior here as I want to get all the window system events to be \
> processed first.
> I tried to verify it by looking at the Qt code and I think it's really the case. \
> See QEventDispatcherUNIX::processEvents \
> (qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp): it first sends the posted \
> events and as very last step activates the timers.
Timer activation should be last action in eventcycle "n" while sending posted event \
the first action in cycle "n+1" (timers are sent and events are posted between the \
two) Since you're adding the timer from a timer event, the present approach would \
likely not even work if there wasn't the maxCount in ::activateTimers() =)
Functionally it's equal (i hope) in this context, BUT (haha!) posting the event will \
*ensure* that a (randomly!) timer triggered action in the core/compositor \
(resize/repaint) will be processed before the next plugin load (which then occurs \
while the compositor sleeps for the next frame) while the mangled qtimer schedule \
*can* prefer the plugin loading (depending on the timer queue), delaying the imminent \
paint =) (Notice that this is academical - if the plugin loading takes some ms, it \
will easily cross a paint timeout)
As a nice addition, one could also have a strictly oo "AutoDeQueue" class (while \
that's likely overengineered unless there'd be interest in a library - or we can use \
it for other parrallel loading until KConfig and friends are guaranteed to be thread \
safe)
Disclaimer: not tested, no guarantee.
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115297/#review48227
-----------------------------------------------------------
On Jan. 24, 2014, 2:52 p.m., Martin Gräßlin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115297/
> -----------------------------------------------------------
>
> (Updated Jan. 24, 2014, 2:52 p.m.)
>
>
> Review request for kwin.
>
>
> Repository: kde-workspace
>
>
> Description
> -------
>
> Keep KWin responsive while loading all effects
>
> Loading all effects during startup can take some time[1] and during
> that time the screen is frozen as the loading blocks the compositor.
>
> This change doesn't load effects directly but puts them into a queue.
> The loading is controlled by a single-shooting QTimer with 0 msec
> interval. Thus we get a firing compositing timer in between and can
> ensure that a frame is rendered when needed and also react to X events
> during the loading.
>
> [1] On my high-end system the set of effects I use take about 200 msec
> to load.
>
>
> Diffs
> -----
>
> kwin/effects.cpp 7da54f4992fcc23989a99e60ec57bcb97c3cc0c3
> kwin/effects.h adcf970a43745cbd44f2510bc0da23aa0450637b
>
> Diff: https://git.reviewboard.kde.org/r/115297/diff/
>
>
> Testing
> -------
>
> Added some debug statements to see whether we get frames rendered between loading. \
> Yes, works.
>
> Thanks,
>
> Martin Gräßlin
>
>
[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="https://git.reviewboard.kde.org/r/115297/">https://git.reviewboard.kde.org/r/115297/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On January 24th, 2014, 3:51 p.m. UTC, <b>Thomas \
Lübking</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; \
border-collapse: collapse; margin: 2px padding: 2px;"> <thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; \
font-size: 9pt; padding: 4px 8px; text-align: left;"> <a \
href="https://git.reviewboard.kde.org/r/115297/diff/1/?file=240441#file240441line198" \
style="color: black; font-weight: bold; text-decoration: \
underline;">kwin/effects.cpp</a> <span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2"></font></th> <td bgcolor="#c5ffc4" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td> <th \
bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid \
#C0C0C0;" align="right"><font size="2">198</font></th> <td bgcolor="#c5ffc4" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span \
class="n">m_timer</span><span class="o">-></span><span class="n">start</span><span \
class="p">();</span></pre></td> </tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">if \
(!m_dequeueIsScheduled) { m_dequeueIsScheduled = true;
QMetaObject::invokeMethod(this, "dequeue", Qt::QueuedConnection);
}
does not abuse QTimer and allows for passing parameters to dequeue (if ever required)
</pre>
</blockquote>
<p>On January 26th, 2014, 10:20 a.m. UTC, <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;">I knew you would suggest \
that :-) Is the behavior really exactly the same? Given the documentation I'm \
unsure about it. For invokeMethod we have: "If type is Qt::QueuedConnection, a \
QEvent will be sent and the member is invoked as soon as the application enters the \
main event loop."
For QTimer with 0 msec we have:
"A QTimer with a timeout interval of 0 will time out as soon as all the events \
in the window system's event queue have been processed."
Given the documentation I understand that invokeMethod will be first in the event \
loop, but the QTimer will be last in the event loop. I might be wrong about that and \
they both behave the same, but in case it's really that difference I want to have \
the QTimer behavior here as I want to get all the window system events to be \
processed first.
I tried to verify it by looking at the Qt code and I think it's really the case. \
See QEventDispatcherUNIX::processEvents \
(qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp): it first sends the posted \
events and as very last step activates the timers.</pre> </blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Timer \
activation should be last action in eventcycle "n" while sending posted \
event the first action in cycle "n+1" (timers are sent and events are \
posted between the two) Since you're adding the timer from a timer event, the \
present approach would likely not even work if there wasn't the maxCount in \
::activateTimers() =)
Functionally it's equal (i hope) in this context, BUT (haha!) posting the event \
will *ensure* that a (randomly!) timer triggered action in the core/compositor \
(resize/repaint) will be processed before the next plugin load (which then occurs \
while the compositor sleeps for the next frame) while the mangled qtimer schedule \
*can* prefer the plugin loading (depending on the timer queue), delaying the imminent \
paint =) (Notice that this is academical - if the plugin loading takes some ms, it \
will easily cross a paint timeout)
As a nice addition, one could also have a strictly oo "AutoDeQueue" class \
(while that's likely overengineered unless there'd be interest in a library - \
or we can use it for other parrallel loading until KConfig and friends are guaranteed \
to be thread safe)
Disclaimer: not tested, no guarantee.</pre>
<br />
<p>- Thomas</p>
<br />
<p>On January 24th, 2014, 2:52 p.m. UTC, Martin Gräßlin wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.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 Jan. 24, 2014, 2:52 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kde-workspace
</div>
<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;">Keep KWin responsive while loading all effects
Loading all effects during startup can take some time[1] and during
that time the screen is frozen as the loading blocks the compositor.
This change doesn't load effects directly but puts them into a queue.
The loading is controlled by a single-shooting QTimer with 0 msec
interval. Thus we get a firing compositing timer in between and can
ensure that a frame is rendered when needed and also react to X events
during the loading.
[1] On my high-end system the set of effects I use take about 200 msec
to load.</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;">Added some debug statements to see whether we get frames rendered \
between loading. Yes, works.</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/effects.cpp <span style="color: \
grey">(7da54f4992fcc23989a99e60ec57bcb97c3cc0c3)</span></li>
<li>kwin/effects.h <span style="color: \
grey">(adcf970a43745cbd44f2510bc0da23aa0450637b)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/115297/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