Improve accuracy of set framerate in GLMakie #3954
Conversation
ffreyer
added
the
GLMakie
Compile Times benchmarkNote, that these numbers may fluctuate on the CI servers, so take them with a grain of salt. All benchmark results are based on the mean time and negative percent mean faster than the base branch. Note, that GLMakie + WGLMakie run on an emulated GPU, so the runtime benchmark is much slower. Results are from running: using_time = @ctime using Backend
# Compile time
create_time = @ctime fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @ctime Makie.colorbuffer(display(fig))
# Runtime
create_time = @benchmark fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @benchmark Makie.colorbuffer(fig)
|
|
I saw something on discourse where they were using a different sleep function for higher accuracy, is that an option? |
|
I came across https://discourse.julialang.org/t/accuracy-of-sleep/5546 / JuliaLang/julia#12770 but on windows |
…kie.jl into ff/frame_time_budget
| function BudgetedTimer(callback, delta_time::Float64, running::Bool, task::Union{Nothing, Task}, min_sleep = 0.015) | ||
| return new(callback, delta_time, min_sleep, 0.0, time_ns(), running, task) | ||
| end |
There was a problem hiding this comment.
I tried timing sleep(0.0001) here but it ended up being inconsistent. Most are 0.015s for me, but some are <0.005s and I assume async tasks and GC can also prolong them. So I just switched to a default value instead.
There was a problem hiding this comment.
Since I wasn't sure anymore I did some testing on what effect a wrong min_sleep has. Doesn't seem like there are any significant changes:
Description
When targeting a framerate GLMakie uses
sleep()which is pretty bad at its job:And thus the frametimes are pretty off. For the default 30fps GLMakie targets we should have 1/30 = 0.033s delay between frames but I get around 0.045:
This pr adds some bookkeeping for the used time per frame. If one frame sleeps for too long the next frame will know about it and sleep for less time. This averages out the frametimes to match the requested framerate.
An alternative option would be have a
while (current_time < frametime) yield()which would be better for stability but I assume would be worse for power usage.Type of change
Checklist