Hi Brian, Am 25.09.2018 um 08:40 schrieb Brian Fraser: > I'm looking for someone to help me understand why Impress uses a timer to > "rebuild the API core from the internal structure", i.e. the > MainSequence::maTimer in MainSequence::startRebuildTimer(). > > I'm working on Bug 118065 (Impress: "UI - Reordering animations is > extremely slow"). I've walked through the code and found the UI does not > redraw the animation list sidebar until after the maTimer expires (timer > currently set to 0.5s). This means that almost anything you do with editing > an animation has a half-second UI lag. > > Why is this done on a timer? The code *seems* to function OK if the timer > is made shorter (0.05s), or even if I call implRebuild() directly from > MainSequnec::startRebuildTimer() (i.e., not use the timer). What kind of > things could go wrong by calling it without the timer, or making the timer > very very short? git blame tells me this code was added to fix https://bz.apache.org/ooo/show_bug.cgi?id=42856 in commit 7c126a4418b ("#i42856# added async updates via vcl timers"). That code is from 2005 and the added comments don't help much either. So my guess is it should be fine to just lower the timeout to some reasonable value (50ms?). There is also some code to handle non-timer UI updates on notification (see MainSequence::getRootNode). Normally you add a timer, if you might get a lot of updates via some code path, so you don't block the UI just for redrawing all the time. So it kind of works like a FPS limiter. For the original bug 500ms was probably enough to show the animations on reload. HTH Jan-Marek _______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice