[core] Support for waiting on events rather than tight polling loop

[JamesDunne]

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.

[raysan5]

Hi @JamesDunne, actually, raylib uses internally GLFW windowing/inputs library for Windows, Linux, macOS platforms, for Android and RaspberryPi it uses custom implementation.

This library uses a wait-for-events alternatives to the usual per-frame event polling. I can try implementing support for it... actually, it's used here.

About power consumption saving, just note you can recompile the library commenting SUPPORT_BUSY_WAIT_LOOP, that way, CPU usage drops because it sleeps remaining target FPS time.

[raysan5]

Just implemented a wait-for-events (only desktop platforms) in commit 0f6f326. Not much tested but seems to work ok.

Just note that raylib should be re-compiled enabling SUPPORT_EVENTS_WAITING flag. Please, let me know if it works ok.

[JamesDunne]

Wow you're fast! I'll take a look later tonight when I get some free time. Thanks!

[raysan5]

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...

Just closing this issue for now...

[JamesDunne]

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.

[raysan5]

Hey @JamesDunne! Yeah, you're right, most probably the O_NONBLOCK comes for the initial implementation when no threads were used... don't remember...

Now I don't have much time to look into it but if you tested it and works, it'd great if you send a PR with the changes.

[raysan5]

Hi @JamesDunne, did you work further on this? Could you send a PR or share a code snippet for review?

[JamesDunne]

Sorry, no I haven't had time to dedicate to this lately.

…

On Sat, Dec 15, 2018, 05:17 Ray ***@***.*** wrote: Hi @JamesDunne <https://github.com/JamesDunne>, did you work further on this? Could you send a PR or share a code snippet for review? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#679 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAg2KDZKopooPzh9frmuAYjIpH-uMgRHks5u5NpMgaJpZM4YE3Fo> .

[raysan5]

Closing this issue for now.