-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement concurrent updates #12
Comments
Proposal 1:
Problem: what if there is no regular frames sent to vsync thread but we have immediate updates in the queue? Proposal 2:
Problem: we introduce more mutex locking by having to enqueue each frame individually (instead of batch generation) |
Thank you for this thorough proposal. Both options seem equally sensible to me. Here are some more thoughts. For proposal 1, having no regular frames to process while there are pending immediate updates would not be an issue (in my opinion), since we can add a condition variable for the immediate queue to wake up the vsync thread when needed. The main issue I can see in proposal 1 is that we loose the ordering between regular updates and immediate updates, since they go to different queues and are processed in different threads. Could this cause visual glitches under some circumstances? If I understand correctly, proposal 2 does not have this issue. Another thing is that proposal 1 would blur the existing separation of concerns between the two threads, which may make it harder to reason about the code. Proposal 2 would retain this separation though, as you mentioned, this comes with the cost of more locking. |
Currently working on implementing proposal 2 on branch immediate. First results on the “spiral” test (left is with old code, right is with immediate mode): waved-2964.mp4Still needs more testing and cleanup before it’s ready. |
No description provided.
The text was updated successfully, but these errors were encountered: