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

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

Closed
JamesDunne opened this issue Oct 31, 2018 · 9 comments

Comments

Projects
None yet
2 participants
@JamesDunne
Copy link

commented Oct 31, 2018

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

This comment has been minimized.

Copy link
Owner

commented Oct 31, 2018

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 raysan5 changed the title Support for waiting on events rather than tight polling loop [core] Support for waiting on events rather than tight polling loop Oct 31, 2018

@raysan5

This comment has been minimized.

Copy link
Owner

commented Oct 31, 2018

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

This comment has been minimized.

Copy link
Author

commented Oct 31, 2018

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

@raysan5

This comment has been minimized.

Copy link
Owner

commented Nov 14, 2018

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

@raysan5 raysan5 closed this Nov 14, 2018

@JamesDunne

This comment has been minimized.

Copy link
Author

commented Nov 14, 2018

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

This comment has been minimized.

Copy link
Owner

commented Nov 14, 2018

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

This comment has been minimized.

Copy link
Owner

commented Dec 15, 2018

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

@JamesDunne

This comment has been minimized.

Copy link
Author

commented Dec 15, 2018

@raysan5 raysan5 added the raspberrypi label Dec 16, 2018

@raysan5

This comment has been minimized.

Copy link
Owner

commented Jan 3, 2019

Closing this issue for now.

@raysan5 raysan5 closed this Jan 3, 2019

@raysan5 raysan5 added this to the raylib 2.5 milestone Feb 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.