summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJan-Marek Glogowski <glogow@fbihome.de>2017-07-31 19:49:34 +0200
committerJan-Marek Glogowski <glogow@fbihome.de>2017-08-01 18:50:24 +0200
commit50799a721c7ddcf9475a1b79984ed64ddd7cdf57 (patch)
tree2be626faa0c8e1513029aba588fd6bfa5daa21ce
parentc90e9ca50300c7f59558095c2716c098632c8d37 (diff)
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
-rw-r--r--vcl/inc/win/saldata.hxx2
-rw-r--r--vcl/win/app/salinst.cxx39
-rw-r--r--vcl/win/app/saltimer.cxx22
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()