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

2014-10-20 Thread Jennifer Liebel
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


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

2014-10-18 Thread 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.me...@collabora.com  , Pseudo Engineer, itinerant idiot
diff --git a/include/vcl/timer.hxx b/include/vcl/timer.hxx
index d3ebe1a..e2cbaa7 100644
--- a/include/vcl/timer.hxx
+++ b/include/vcl/timer.hxx
@@ -73,6 +73,41 @@ public:
 AutoTimer  operator=( const AutoTimer rTimer );
 };
 
+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
+};
+
+
+// To port from Timer - Idle switch class name,
+// s/Timeout/DoIdle/ etc. and select priority
+class VCL_DLLPUBLIC Idle : private Timer
+{
+ public:
+Idle( IdlePriority ePriority );
+virtual ~Idle();
+
+void SetPriority( IdlePriority ePriority );
+
+/// Make it possible to associate a callback with this idle handler
+/// of course, you can also sub-class and override 'DoIdle'
+voidSetIdleHdl( const Link rLink ) { SetTimeoutHdl( rLink ); }
+const Link GetIdleHdl() const  { return GetTimeoutHdl(); }
+
+voidStart() { Timer::Start(); }
+voidStop()  { Timer::Stop();  }
+
+virtual voidDoIdle() = 0;
+
+virtual voidTimeout() SAL_OVERRIDE { DoIdle(); }
+};
+
 #endif // INCLUDED_VCL_TIMER_HXX
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/vcl/inc/window.h b/vcl/inc/window.h
index 4448c55..9c8cb08 100644
--- a/vcl/inc/window.h
+++ b/vcl/inc/window.h
@@ -127,8 +127,8 @@ struct ImplOverlapData
 
 struct ImplFrameData
 {
-Timer   maPaintTimer;   // paint timer
-Timer   maResizeTimer;  // resize timer
+IdlemaPaintIdle;// paint idle handler
+IdlemaResizeTimer;  // resize timer
 InputContextmaOldInputContext;  // last set Input Context
 vcl::Window*mpNextFrame;// next frame window
 vcl::Window*mpFirstOverlap; // first overlap vcl::Window
diff --git a/vcl/source/app/timer.cxx b/vcl/source/app/timer.cxx
index ecbfa74..a1b4a18 100644
--- a/vcl/source/app/timer.cxx
+++ b/vcl/source/app/timer.cxx
@@ -336,4 +336,49 @@ AutoTimer AutoTimer::operator=( const AutoTimer rTimer )
 return *this;
 }
 
+Idle::Idle( IdlePriority ePriority )
+: Timer()
+{
+SetPriority( ePriority );
+}
+
+void Idle::SetPriority( IdlePriority ePriority )
+{
+sal_ulong nTimeoutMS = 0;
+
+// Ultimately this will just be a sort key in a work queue.
+switch (ePriority) {
+	case VCL_IDLE_PRIORITY_HIGHEST:
+nTimeoutMS = 0;
+break;
+	case VCL_IDLE_PRIORITY_HIGH:
+nTimeoutMS = 1;
+break;
+	case VCL_IDLE_PRIORITY_REPAINT:
+nTimeoutMS = 30;
+break;
+	

Main-loop / idle handler bits ...

2014-10-01 Thread Michael Meeks
Hi Florian,

On Wed, 2014-10-01 at 16:55 +0200, Florian Haftmann wrote:
 The current matter of affairs is now documented in the Wiki.
 https://wiki.documentfoundation.org/Development/LHM_LiMux#Priority_Main_Loop

 To be continued…

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 - clearly we don't want to screw with those -
humans don't get faster reactions with better CPUs ;-)

Then we should rank and prioritise all the small value timeouts into a
series of grouped 'idle' priorities [ some integer ranking I guess cf.
glib idle handlers ] which we can use in place of any timeout to ensure
these are executed as quickly as possible (absent any other timeout) but
in a way that makes reasonable sense =)

Does that make sense ?

Thanks !

Michael.

-- 
 michael.me...@collabora.com  , Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice