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.
Can raylib support a wait-for-events model in contrast to a tight loop polling for events and rendering at a target fps? This would lighten up resource utilization on embedded platforms like the Raspberry Pi as well as ease power consumption in general. It's not for every scenario of course but it would be a nice option to have.
The text was updated successfully, but these errors were encountered:
As a side note, Raspberry Pi does not support this feature at this moment in native mode; inputs are processed in a second thread at higher speed, it would be possible to wait for input events but it won't stop screen drawing in main thread... well, drawing can also avoid SUPPORT_BUSY_WAIT_LOOP for performance improvement...
Yeah I noticed that implementation for RPi, which made me curious. Is there a reason to open the devices in O_NONBLOCK mode while implementing a busy-wait loop in the reading thread (read + usleep)? Why not just turn of non-blocking mode and issue blocking reads on the thread? That would make sure you get updates more on time I would think.
For SUPPORT_EVENTS_WAITING, that threaded code could be replaced with a simple select call and go read the fds that are ready for reading. No extra input threads needed at that point. I've prototyped this out in my own project and it works a charm.