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.me...@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.me...@collabora.com <><, Pseudo Engineer, itinerant idiot >
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice