You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is caused because the time step is currently a constant and every frame is a simulation tick. Fixing this will require keeping track of the actual frame rate, or perhaps the average over several frames. Then we use that as a time step. The simulation should then be consistent regardless of screen.
We could also somehow get the display refresh rate and use that, but it wouldn't be guaranteed to match the actual frame rate so there might be jank, which is bad. If the application can't render at the native frame rate, if it drops frames, this should not affect the simulation.
The text was updated successfully, but these errors were encountered:
Fix Force directed layout slower on 60hz displays #16
The time step of the force-directed layout is now based on the current frame rate.
Dragging a window between a 60hz display and a 120hz display now works propertly. This should even account for frame dropping.
The time step is smoothed with each new step being averaged with the last acounting for frame pacing issues and jitter.
Additionally, a speed slider has been added to the UI to control a multiplier to the time step.
Fix Force directed layout slower on 60hz displays #16
The time step of the force-directed layout is now based on the current frame rate.
Dragging a window between a 60hz display and a 120hz display now works propertly. This should even account for frame dropping.
The time step is smoothed with each new step being averaged with the last acounting for frame pacing issues and jitter.
Additionally, a speed slider has been added to the UI to control a multiplier to the time step.
This is caused because the time step is currently a constant and every frame is a simulation tick. Fixing this will require keeping track of the actual frame rate, or perhaps the average over several frames. Then we use that as a time step. The simulation should then be consistent regardless of screen.
We could also somehow get the display refresh rate and use that, but it wouldn't be guaranteed to match the actual frame rate so there might be jank, which is bad. If the application can't render at the native frame rate, if it drops frames, this should not affect the simulation.
The text was updated successfully, but these errors were encountered: