diff options
| author | Jan-Marek Glogowski <glogow@fbihome.de> | 2017-10-12 18:19:12 +0200 |
|---|---|---|
| committer | Jan-Marek Glogowski <glogow@fbihome.de> | 2017-10-13 16:49:22 +0200 |
| commit | abe3af8e9871907aa75b913f2b8094cac651bc6d (patch) | |
| tree | c3a4a6a623988d3d79c12baff6c4dcf624055c1a /vcl/README.scheduler | |
| parent | 3bf6c97029d26ddf20007c47ca6b68e5cc52d846 (diff) | |
WIN fix redraw during window move and resize
During window move and resize, Windows spawns a nested message
loop, blocking our direct processing. In this case we switch to
timer messages for all timeouts.
But if LO is busy with background jobs, the posted 0ms timer
messages will block any system event processing, halting any
updates until we're idle again. So for these cases we switch
to the WM_TIMER based SetTimer timer.
Change-Id: I854f4984d7c75d6829f82cda5cb4479967edce48
Reviewed-on: https://gerrit.libreoffice.org/43350
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Diffstat (limited to 'vcl/README.scheduler')
| -rw-r--r-- | vcl/README.scheduler | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/vcl/README.scheduler b/vcl/README.scheduler index a052dd420c74..566a88629301 100644 --- a/vcl/README.scheduler +++ b/vcl/README.scheduler @@ -187,6 +187,15 @@ the system message wasn't already our timer. As a result we can also skip the polling. All this is one more reason to drop the single message processing in favour of always processing all pending (system) events. +There is an other special case, we have to handle: window updates during move +and resize of windows. These system actions run in their own nested message +loop. So we have to completely switch to timers, even for 0ms. But these +posted events prevent any event processing, while we're busy. The only viable +solution seems to be to switch to WM_TIMER based timers, as these generate +messages with the lowest system priority (but they don't allow 0ms timeouts). +So processing slows down during resize and move, but we gain working painting, +even when busy. + An additional workaround is implemented for the delayed queuing of posted messages, where PeekMessage in WinSalTimer::Stop() won't be able remove the just posted timer callback message. See "General: invalidation of elapsed |