Am 30.06.21 um 15:14 schrieb Jan-Marek Glogowski:
You could override the Invoke function of the AutoTimer to do that for
all. Or...
Or so I assumed; the code from:
else if (bTaskAlive)
{
pMostUrgent->mnUpdateTime = nTime;
will override the mnUpdateTime set by
Am 30.06.21 um 14:53 schrieb Stephan Bergmann:
On 30/06/2021 14:36, Jan-Marek Glogowski wrote:
Am 30.06.21 um 14:29 schrieb Stephan Bergmann:
On 29/06/2021 18:51, Noel Grandin wrote:
I have seen the same problem in another application I maintain.
My solution is that the repeat-delay time
On 30/06/2021 14:36, Jan-Marek Glogowski wrote:
Am 30.06.21 um 14:29 schrieb Stephan Bergmann:
On 29/06/2021 18:51, Noel Grandin wrote:
I have seen the same problem in another application I maintain.
My solution is that the repeat-delay time specified in my timers is
always the time between
Am 30.06.21 um 14:29 schrieb Stephan Bergmann:
On 29/06/2021 18:51, Noel Grandin wrote:
I have seen the same problem in another application I maintain.
My solution is that the repeat-delay time specified in my timers is
always the time between the end of one invocation of a timer, and the
On 29/06/2021 18:51, Noel Grandin wrote:
I have seen the same problem in another application I maintain.
My solution is that the repeat-delay time specified in my timers is
always the time between the end of one invocation of a timer, and the
start of the next invocation of that timer.
Yes,
Michael Stahl wrote:
> but perhaps we have timers that need to run at e.g. 60hz like for
> example animations in slideshows?
>
Since we never got woken up at the right time anyway, this is not
needed for slideshow. One would rather render everything, wait for the
vblank, rinse and repeat...
On 29/06/2021 18.51, Noel Grandin wrote:
I have seen the same problem in another application I maintain.
My solution is that the repeat-delay time specified in my timers is
always the time between the end of one invocation of a timer, and the
start of the next invocation of that timer.
I have seen the same problem in another application I maintain.
My solution is that the repeat-delay time specified in my timers is always
the time between the end of one invocation of a timer, and the start of the
next invocation of that timer.
___
My slow ASan+UBSan Linux builds sometimes livelock in e.g.
UITest_calc_tests8: The soffice.bin main thread's event loop at
[...]
#33 0x7f7fe8ea35dc in ScAreaLink::RefreshHdl(Timer*) (this=0x611000891240)
at sc/source/ui/docshell/arealink.cxx:492
#34 0x7f7fe8e920a9 in
