From 50799a721c7ddcf9475a1b79984ed64ddd7cdf57 Mon Sep 17 00:00:00 2001 From: Jan-Marek Glogowski Date: Mon, 31 Jul 2017 19:49:34 +0200 Subject: 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 --- vcl/inc/win/saldata.hxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'vcl/inc') 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 -- cgit