Main-loop / idle handler bits ...

Michael Meeks michael.meeks at
Sat Oct 18 12:57:51 PDT 2014

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'

	How is that coming along? I see lots of nice things in the wiki page

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_HIGH, //      -> 1ms
	VCL_IDLE_PRIORITY_LOW //        -> 100ms
	VCL_IDLE_PRIORITY_LOWER //      -> 200ms

	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.meeks at  <><, Pseudo Engineer, itinerant idiot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scratch-un-compiled-idle.patch
Type: text/x-patch
Size: 4688 bytes
Desc: not available
URL: <>

More information about the LibreOffice mailing list