tdf#109997 WIN don't post a callback event directly

I doesn't seem possible to post an event deterministically to the
end of the Windows message queue and then process this queued
events "in order".

PeekMessage and now even DispatchMessage process events out of
order - that's how this assert was hit. I was quite sure it would
not hit, but a simple resize proved me wrong. And the assert just
proved that all my assumptions were wrong :-(

So this gives up the whole idea of a short-circuit message queue
handling on Windows for busy processing of LO Idles and goes back
to some kind of the original "always timer" implementation. Since
the "parallel" processing of LO events after system messages
during DoYield  was dropped, this might be slower; or not.

In the end this simplifies the main loop almost to the starting
point, except for a little busy loop, if we wait for an Idle event
timer - not so busy acually, as we just switch to another local
thread, which hopefully is our idle timer waiting to fire.
A short-circuit with a little detour.

Change-Id: Id63a2a9e2a3b1501ad50a2c6f308a36efe55e68f

3 files changed, 20 insertions, 43 deletions

diff --git a/vcl/inc/win/saldata.hxx b/vcl/inc/win/saldata.hxx
index ed1d225b14b8..9ad5d9cfddf1 100644
--- a/vcl/inc/win/saldata.hxx
+++ b/vcl/inc/win/saldata.hxx
@@ -85,7 +85,7 @@ public:
     BYTE*                   mpDitherLow;            // Dither mapping table
     BYTE*                   mpDitherHigh;           // Dither mapping table
     HANDLE                  mnTimerId;              ///< Windows timer id
-    bool                    mbOnIdleRunScheduler;   ///< Run the scheduler, if yield is idle
+    bool                    mbOnIdleRunScheduler;   ///< Run yield until the scheduler processed the idle
     HHOOK                   mhSalObjMsgHook;        // hook to get interesting msg for SalObject
     HWND                    mhWantLeaveMsg;         // window handle, that want a MOUSELEAVE message
     AutoTimer*              mpMouseLeaveTimer;      // Timer for MouseLeave Test
diff --git a/vcl/win/app/salinst.cxx b/vcl/win/app/salinst.cxx
index 6458fca73c43..7ea3bd526675 100644
--- a/vcl/win/app/salinst.cxx
+++ b/vcl/win/app/salinst.cxx
@@ -575,29 +575,20 @@ ImplSalYield( bool bWait, bool bHandleAllCurrentEvents )
         if ( bOneEvent )
         {
             bWasMsg = true;
-            if ( !(aMsg.message == SAL_MSG_TIMER_CALLBACK && 1 == aMsg.wParam) )
-            {
-                TranslateMessage( &aMsg );
-                ImplSalDispatchMessage( &aMsg );
-            }
-            else
-            {
-                // This is just the scheduler wakeup message, in case we're
-                // waiting in GetMessageW
-                // So we can just drop it, but we have to fix the accounting!
-                assert( pSalData->mbOnIdleRunScheduler );
-                ++nMaxEvents;
-            }
+            TranslateMessage( &aMsg );
+            ImplSalDispatchMessage( &aMsg );
         }
         else
-        {
-            if ( nMaxEvents && pSalData->mbOnIdleRunScheduler )
+            // busy loop to catch the 0ms timeout
+            // We don't need to busy loop, if we wait anyway.
+            // Even if we didn't process the event directly, report it.
+            if ( pSalData->mbOnIdleRunScheduler && !bWait )
             {
-                pSalData->mbOnIdleRunScheduler = false;
-                EmitTimerCallback();
+                SwitchToThread();
+                nMaxEvents++;
                 bOneEvent = true;
+                bWasMsg = true;
             }
-        }
     } while( --nMaxEvents && bOneEvent );
 
     // Also check that we don't wait when application already has quit
@@ -606,11 +597,8 @@ ImplSalYield( bool bWait, bool bHandleAllCurrentEvents )
         if ( GetMessageW( &aMsg, nullptr, 0, 0 ) )
         {
             // Ignore the scheduler wakeup message
-            if ( !(aMsg.message == SAL_MSG_TIMER_CALLBACK && 1 == aMsg.wParam) )
-            {
-                TranslateMessage( &aMsg );
-                ImplSalDispatchMessage( &aMsg );
-            }
+            TranslateMessage( &aMsg );
+            ImplSalDispatchMessage( &aMsg );
         }
     }
     return bWasMsg;
@@ -735,9 +723,8 @@ LRESULT CALLBACK SalComWndProc( HWND, UINT nMsg, WPARAM wParam, LPARAM lParam, i
             while ( PeekMessageW(&aMsg, nullptr, SAL_MSG_TIMER_CALLBACK,
                                  SAL_MSG_TIMER_CALLBACK, PM_REMOVE | PM_NOYIELD | PM_QS_POSTMESSAGE) )
                 assert( "Multiple timer messages in queue" );
-            assert( 0 == wParam );
-            if ( 0 == wParam )
-                EmitTimerCallback();
+            GetSalData()->mbOnIdleRunScheduler = false;
+            EmitTimerCallback();
             break;
     }
 
diff --git a/vcl/win/app/saltimer.cxx b/vcl/win/app/saltimer.cxx
index 847ff52851b8..d57eefd63efc 100644
--- a/vcl/win/app/saltimer.cxx
+++ b/vcl/win/app/saltimer.cxx
@@ -53,7 +53,6 @@ void ImplSalStopTimer()
                          SAL_MSG_TIMER_CALLBACK, PM_REMOVE | PM_NOYIELD | PM_QS_POSTMESSAGE) )
         nMsgCount++;
     assert( nMsgCount <= 1 );
-    pSalData->mbOnIdleRunScheduler = false;
 }
 
 void ImplSalStartTimer( sal_uLong nMS )
@@ -68,22 +67,13 @@ void ImplSalStartTimer( sal_uLong nMS )
     // cannot change a one-shot timer, so delete it and create a new one
     ImplSalStopTimer();
 
-    // run the scheduler, if yield is idle for the 0ms case
+    // keep the scheduler running, if a 0ms timer / Idle is scheduled
     pSalData->mbOnIdleRunScheduler = ( 0 == nMS );
-    if ( pSalData->mbOnIdleRunScheduler )
-    {
-        BOOL const ret = PostMessageW(pSalData->mpFirstInstance->mhComWnd,
-                                      SAL_MSG_TIMER_CALLBACK, 1, 0);
-        SAL_WARN_IF(0 == ret, "vcl", "ERROR: PostMessage() failed!");
-    }
-    else
-    {
-        // probably WT_EXECUTEONLYONCE is not needed, but it enforces Period
-        // to be 0 and should not hurt; also see
-        // https://www.microsoft.com/msj/0499/pooling/pooling.aspx
-        CreateTimerQueueTimer(&pSalData->mnTimerId, nullptr, SalTimerProc, nullptr,
-                              nMS, 0, WT_EXECUTEINTIMERTHREAD | WT_EXECUTEONLYONCE);
-    }
+    // probably WT_EXECUTEONLYONCE is not needed, but it enforces Period
+    // to be 0 and should not hurt; also see
+    // https://www.microsoft.com/msj/0499/pooling/pooling.aspx
+    CreateTimerQueueTimer(&pSalData->mnTimerId, nullptr, SalTimerProc, nullptr,
+                          nMS, 0, WT_EXECUTEINTIMERTHREAD | WT_EXECUTEONLYONCE);
 }
 
 WinSalTimer::~WinSalTimer()