| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The code did acccount processing of an invaild timeout system
message as a valid timeout event.
Change-Id: I3c31f8b9cec592631b4089411163dadecffde816
Reviewed-on: https://gerrit.libreoffice.org/43529
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
It seems that something filters application defined events when
closing a window... DoYield expects a timeout event, which never
arrives, stopping all redraw and generating a busy loop.
Change-Id: Ic83468cceac7b967acaecf18b321178fc7565b94
Reviewed-on: https://gerrit.libreoffice.org/43381
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
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>
|
|
This time we skip the intention to handle our Scheduler
completely via the system event loop. Instead we basically
guarantee to process a Scheduler event during each DoYield,
if one is available. This way we won't block system events
when busy in our event loop.
Change-Id: I37094e61cbf928733151d9cc3299cdac76b3a5cd
Reviewed-on: https://gerrit.libreoffice.org/43349
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Instead of storing the system ticks in the timer event message
simply store a version.
Moves the version handling code into a VersionedEvent class,
inherited by WinSalTimer and AquaSalTimer.
Change-Id: I5add85031d36b3424a26a9ef798294cbfb00b2e4
Reviewed-on: https://gerrit.libreoffice.org/42959
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This prevents blocking the main thread by a yielding non-main thread.
The current solution is to wait on a condition, which is set by the
main thread on wakeup.
Change-Id: I8d680bb51a36ce1e0d3d4713d47d8e2ef93d7297
Reviewed-on: https://gerrit.libreoffice.org/42808
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I9aaefa47399f35d563c1a4df364512dd29db41ce
Reviewed-on: https://gerrit.libreoffice.org/42817
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Id8f863963cb2f34d81f2ad82353caaa2d03d59be
Reviewed-on: https://gerrit.libreoffice.org/42807
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Application::Reschedule(true) must just process all currently
pending events and ignore all new events generated while processing
them. In contrast to Scheduler::ProcessEventsToIdle, this way it
can't busy-lock the application with background jobs.
This way we also can drop nMaxEvents from the Windows backend. This
limit was also never implemented on OSX and for the KDE4 backend
it's actually impossible to handle single events, and a call to
QAbstractEventDispatcher::processEvents works like this.
Also changes various call sites to just process all pending events
instead of some made up number of times.
Change-Id: I1ab95df89b079cc8c6319a808194fe3127144d1c
Reviewed-on: https://gerrit.libreoffice.org/42659
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This way we can drop all the special nReleased handling. Instead
we use the same mechanism as on Mac, where we keep the lock, but
disable it for the main thread. As a security measure we assert on
duplicate redirects, which should not happen.
As a result we can't use SendMessage on the main thread itself,
which would normally just call the WinProc directly. This could be
accomplished by converting the redirect bool into a counter, which
should be safe, as no other thread could acquire the SolarMutex,
as we don't release it.
Change-Id: Icd87b3da37a2489f3cad2bc80215bf93fc41d388
Reviewed-on: https://gerrit.libreoffice.org/42583
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Fixes the "Multiple timers in queue" assertion by effectively
removing it.
When debugging it became obvious, that PostMessage returns, even
if the message was not yet added to the message queue.
The assert happens, because we start the timer in the Scheduler
before Invoke(), so it fires, if we block in Invoke(), and then
reset the timer after Invoke, if there were changes to the Task
list.
In this case it fires during Invoke(), the message is added. We
restart the timer, first by stopping it (we wait in
DeleteTimerQueueTimer, to be sure the timer function has either
finished or was not run). And the try to remove the message with
PeekMessageW, which doesn't remove the posted message.
Then the timer is restarted, and when the event is processed, we
end up with an additional timer event, which was asserted.
As a fix this adds a (microsecond) timestamp to the timer message,
which is validated in the WinProc function. So if we stop the
timer too fast, the event is ignored based on the timestamp.
And while at it, the patch moves timer related variables from
SalData into WinSalTimer.
Change-Id: Ib840a421e8bd040d40f39473e1d44491e5b332bd
Reviewed-on: https://gerrit.libreoffice.org/42575
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I51700733fda3a08570085ed6745961cd1680eabd
Reviewed-on: https://gerrit.libreoffice.org/42588
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
A task has to get the SchedulerLock to remove itself from the
Scheduler list. This doesn't work, if the Task is static, as the
static Scheduler might be destroyed earlier. In this case we fail
with the following backtrace:
#0 SchedulerMutex::acquire
#1 Task::~Task
#2 __run_exit_handlers
Thanks to Michael Stahl to catching this backtrace.
As a workaround this marks static tasks, so they ignore the
SchedulerMutex in the destructor, We also mark all scheduled Tasks
as "static" in DeInitScheduler, as their cleanup was already done.
In the end all Tasks should be removed from static objects.
Change-Id: I38be3206378b9449193efaccbc96896ac8de9478
Reviewed-on: https://gerrit.libreoffice.org/42574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
The extension manager starts dialogs from its own thread. But the
OSX backend currently doesn't defer these calls to the main thread.
This implements the deference by running the called function
in the main thread, using a code ^Block, and returning the result
via a SalYieldMutex member.
Change-Id: Id8977991e3eda91da27c23d8021e028d4f4cefe5
Reviewed-on: https://gerrit.libreoffice.org/42448
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
While resizing MacOS suspends the NSDefaultRunLoopMode. So in this
caae we can't post to the system event loop, but must use timers
to restart ourself.
Since the timer itself is scheduled on the NSEventTrackingRunLoopMode
it' also triggers on resize events.
There is still some minor glitch: when resizing too fast some part of
LibreOffice isn't painted, while the left mouse button is down.
Since there isn't any layouting triggered by the mouse up, there has
to be an other inconsistency.
Change-Id: I3ccba78bd23ec8526f21e7b93b027f3d3279f901
|
|
Change-Id: Iaa9c0aea3ea1a239e378bd714ba335f91bb1faf3
Reviewed-on: https://gerrit.libreoffice.org/41194
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ifb2332b6d3c8bf472c684d3a79c861cc9035d246
|
