https://bugs.documentfoundation.org/show_bug.cgi?id=148435
--- Comment #44 from Michael Meeks <[email protected]> --- This is really grim: Calling: AquaSalInstance::AnyInput(VclInputFlags) Seems to lead to un-controlled re-enterancy that is completely un-related to input - to whit creating new windows, and re-sizing them - which triggers re-rendering: amazing Apple API ;-) I can't see any way to only look for input events in this API either. Anyhow - good to be aware of this I suppose: And we have Scheduler::CallbackTaskScheduling https://opengrok.libreoffice.org/xref/core/vcl/source/app/scheduler.cxx?r=91ba9654&mo=11629&fi=330#426 which takes the mutex, and then calls AquaSalInstance::AnyInput(VclInputFlags) https://opengrok.libreoffice.org/xref/core/vcl/osx/salinst.cxx?r=467085bf#676 which calls I expect the 'easiest' fix is to move the check for AnyInput down the function some way so this: 422 // Delay invoking tasks with idle priorities as long as there are user input or repaint events 423 // in the OS event queue. This will often effectively compress such events and repaint only 424 // once at the end, improving performance in cases such as repeated zooming with a complex document. 425 if ( pMostUrgent && pMostUrgent->mePriority >= TaskPriority::HIGH_IDLE 426 && Application::AnyInput( VclInputFlags::MOUSE | VclInputFlags::KEYBOARD | VclInputFlags::PAINT )) 427 { 428 SAL_INFO( "vcl.schedule", tools::Time::GetSystemTicks() 429 << " idle priority task " << pMostUrgent << " delayed, system events pending" ); 430 pMostUrgent = nullptr; 431 nMinPeriod = 0; 432 } Happens after the 'Unlock()' - of course - if we find that now is not a good time to process this event after the unlock - then we should not pTask->Invoke() and then re-add the pTask to the scheduler, mend the scheduler stack etc. again. at the end. Possibly to do that we need to clobber bTaskAlive in this case - but quite possibly nothing much more needs doing. -- You are receiving this mail because: You are the assignee for the bug.
