<div dir="ltr"><div><div><div><div><div>Hi Michael,<br><br></div>we have a new wiki page. Can you check it, if we have the proper information?<br><a href="https://wiki.documentfoundation.org/Development/LHM_LiMux/Main_Loop">https://wiki.documentfoundation.org/Development/LHM_LiMux/Main_Loop</a><br><br>We acquired a scheduling concept:<br></div>Scheduling with priorities: Every Timer gets a default priority. To avoid starvation, the priority increases after every cycle (dynamic priorities). When it was executed, it gets the default priority again.<br></div><br></div>Do you agree?<br><br></div>Kind regards<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-18 21:57 GMT+02:00 Michael Meeks <span dir="ltr"><<a href="mailto:michael.meeks@collabora.com" target="_blank">michael.meeks@collabora.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi guys,<br>
<br>
        Just wondering how this is going =) I could really use an UNO method<br>
that essentially processes all 'idle' handlers synchronously to finish<br>
up all pending work - to help with some profiling tasks - but (of<br>
course) to do that, we need some genuine 'idle' vs. 'timeout'<br>
distinction.<br>
<br>
        How is that coming along? I see lots of nice things in the wiki page<br>
here:<br>
<br>
<a href="https://wiki.documentfoundation.org/Development/LHM_LiMux#Priority_Main_Loop" target="_blank">https://wiki.documentfoundation.org/Development/LHM_LiMux#Priority_Main_Loop</a><br>
<span class=""><br>
On Wed, 2014-10-01 at 17:04 +0100, Michael Meeks wrote:<br>
>       Yep - a very helpful table there. I've asked to have that sorted by<br>
> timeout not source-location; and to have all the UI related timeouts<br>
</span>> split to their own section.<br>
<br>
        So - I did some thinking and mapped the timeouts to some sort of<br>
descriptive priority names - something like this:<br>
<br>
enum IdlePriority {<br>
        VCL_IDLE_PRIORITY_HIGHEST, //   -> 0ms<br>
        VCL_IDLE_PRIORITY_HIGH, //      -> 1ms<br>
        VCL_IDLE_PRIORITY_REPAINT //    -> 30ms<br>
        VCL_IDLE_PRIORITY_RESIZE  //    -> 50ms<br>
        VCL_IDLE_PRIORITY_MEDIUM //     -> 50ms<br>
        VCL_IDLE_PRIORITY_LOW //        -> 100ms<br>
        VCL_IDLE_PRIORITY_LOWER //      -> 200ms<br>
        VCL_IDLE_PRIORITY_LOWEST //     -> 400ms<br>
};<br>
<br>
        we can rip/replace the 'ms' comments later of course. Then we would<br>
need a patch something like the attached. Of course, worked through all<br>
of the instances of idle handlers =) Patch is un-tested to avoid having<br>
to trigger a rather slow re-build here; please do hack it about into<br>
whatever form you like.<br>
<br>
        Is it possible to extend that suitably ? when we have the code changed<br>
around the place, and the problem isolated; we can start to prioritize<br>
and avoid having these silly timeouts at all (I hope).<br>
<br>
        Having said that, when we get to 400ms - I imagine this is a UI<br>
interaction timeout - which prolly should stay at 400ms ;-) - it'd be<br>
good to review those to see if they are UI / behaviour related - it'd<br>
suck to suddenly have the double-click time be ~instant ;-)<br>
<br>
        All the best,<br>
<div class="HOEnZb"><div class="h5"><br>
                Michael.<br>
<br>
--<br>
 <a href="mailto:michael.meeks@collabora.com">michael.meeks@collabora.com</a>  <><, Pseudo Engineer, itinerant idiot<br>
</div></div></blockquote></div><br></div>