Re: Main-loop / idle handler bits ...

Hi Michael,

we have a new wiki page. Can you check it, if we have the proper
information?
https://wiki.documentfoundation.org/Development/LHM_LiMux/Main_Loop

We acquired a scheduling concept:
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.

Do you agree?

Kind regards

2014-10-18 21:57 GMT+02:00 Michael Meeks <michael.meeks@collabora.com>:

> Hi guys,
>
>         Just wondering how this is going =) I could really use an UNO
> method
> that essentially processes all 'idle' handlers synchronously to finish
> up all pending work - to help with some profiling tasks - but (of
> course) to do that, we need some genuine 'idle' vs. 'timeout'
> distinction.
>
>         How is that coming along? I see lots of nice things in the wiki
> page
> here:
>
>
> https://wiki.documentfoundation.org/Development/LHM_LiMux#Priority_Main_Loop
>
> On Wed, 2014-10-01 at 17:04 +0100, Michael Meeks wrote:
> >       Yep - a very helpful table there. I've asked to have that sorted by
> > timeout not source-location; and to have all the UI related timeouts
> > split to their own section.
>
>         So - I did some thinking and mapped the timeouts to some sort of
> descriptive priority names - something like this:
>
> enum IdlePriority {
>         VCL_IDLE_PRIORITY_HIGHEST, //   -> 0ms
>         VCL_IDLE_PRIORITY_HIGH, //      -> 1ms
>         VCL_IDLE_PRIORITY_REPAINT //    -> 30ms
>         VCL_IDLE_PRIORITY_RESIZE  //    -> 50ms
>         VCL_IDLE_PRIORITY_MEDIUM //     -> 50ms
>         VCL_IDLE_PRIORITY_LOW //        -> 100ms
>         VCL_IDLE_PRIORITY_LOWER //      -> 200ms
>         VCL_IDLE_PRIORITY_LOWEST //     -> 400ms
> };
>
>         we can rip/replace the 'ms' comments later of course. Then we would
> need a patch something like the attached. Of course, worked through all
> of the instances of idle handlers =) Patch is un-tested to avoid having
> to trigger a rather slow re-build here; please do hack it about into
> whatever form you like.
>
>         Is it possible to extend that suitably ? when we have the code
> changed
> around the place, and the problem isolated; we can start to prioritize
> and avoid having these silly timeouts at all (I hope).
>
>         Having said that, when we get to 400ms - I imagine this is a UI
> interaction timeout - which prolly should stay at 400ms ;-) - it'd be
> good to review those to see if they are UI / behaviour related - it'd
> suck to suddenly have the double-click time be ~instant ;-)
>
>         All the best,
>
>                 Michael.
>
> --
>  michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot