Closed ilmai closed 9 months ago
FWIW this doesn't happen on Windows, where I'm using IDXGIOutput.WaitForVBlank()
for vsync. On Mac I'm using CVDisplayLink
.
Switching my Mac to 60Hz refresh rate doesn't help.
Out of curiousity, do you re-implement Platform::duration_since_start in a way that is not monotonic? Just asking if it is possible to go back in time with your platform?
I have not reimplemented it.
This was actually an issue with my custom platform after all. As described on Mattermost: I was calling update_timers_and_animations()
from the wrong thread, and update_timers()
is also called from process_mouse_input()
, so time was being set alternatively to the real duration and 0. Maybe there could be a check somewhere to make it easier to catch a weird error like this?
I will close this issue now, but I opened #3491 to track making clock issues more discoverable.
In addition to detect non monotonic clock, we should also make sure that calling update_timers_and_animations from the wrong thread don't impact the animations in another thread.
I don't understand how this was actually possible, we are using thread_local storage. Calling it from the wrong thread should only update it in its thread_local variable that shouldn't be used.
Were you using the unsafe-single-threaded
feature and not the std
feature? (That doesn't seem possible since i can see skia in the backtrace that needs std
)
I'm using slint with "accessibility", "compat-1-2" and "std" features, with default features turned off.
Close this as https://github.com/slint-ui/slint/issues/3491 should take care of it
I marked this as an enhancement to stop this from showing up in the list of unlabeled issues.
I think Olivier meant to close this :)
I'm working on a custom backend, and encountered this panic when I try to test animation. I'm calling
update_timers_and_animations()
at monitor refresh rate in case that's relevant, which on my Macbook is apparently adaptive and up to 120Hz.Here's the test component I'm using:
Here's the relevant part of the stack trace: