Skip to content
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

Move graphics functions to threads #6

Closed
cyberbit opened this issue Jun 18, 2017 · 2 comments
Closed

Move graphics functions to threads #6

cyberbit opened this issue Jun 18, 2017 · 2 comments
Assignees

Comments

@cyberbit
Copy link
Owner

This will keep the client responsive. Will need to test command overlap when running animations.

@cyberbit cyberbit self-assigned this Jun 18, 2017
@cyberbit
Copy link
Owner Author

Command overlap causes weird graphical glitches and eventually failure of the device. Will consider using a queue to schedule graphics commands, or implementing a singleton policy that cancels the currently running thread if another is requested.

cyberbit added a commit that referenced this issue Jun 19, 2017
There are some overlap issues with threads. Need to implement a
queue to avoid crashing the device. There is also an outstanding bug
with the CMD_ACK handler that seems to process a command for every
byte sent by the client, which fills the buffer and messes up other
commands.
@cyberbit
Copy link
Owner Author

Command overlap is pretty much solved in the next commit. Only one graphics thread runs at a time, synchronized by a global thread ID variable. When a thread is started, a random ID is stored globally. During the critical section (frame loop), the current thread ID is checked against the global ID. If they do not match, the loop is skipped, and eventually the thread is cleaned up and stopped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant