Main-loop / idle handler bits ...

[Michael Meeks]

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 at collabora.com  <><, 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: <http://lists.freedesktop.org/archives/libreoffice/attachments/20141018/cf52f84e/attachment.bin>