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
Split Sdl2Application mainLoopIteration #577 #580
base: master
Are you sure you want to change the base?
Split Sdl2Application mainLoopIteration #577 #580
Conversation
Codecov Report
@@ Coverage Diff @@
## master #580 +/- ##
=======================================
Coverage 82.53% 82.53%
=======================================
Files 531 531
Lines 37613 37613
=======================================
Hits 31043 31043
Misses 6570 6570 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Terribly sorry for taking ages to reply -- I had just a week off but the pile of emergency things to look at grew a lot during that time, so I only got to this PR now.
Oh and thank you for willing to implement this change for the other applications as well, I appreciate that.
bool Sdl2Application::mainLoopTickEventIteration() { | ||
if(!(_flags & Flag::NoTickEvent)) { | ||
tickEvent(); | ||
return true; | ||
} | ||
return false; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this for a bit, and personally I wouldn't even add any mainLoopTickEventIteration()
-- keep the code directly inside mainLoopIteration()
.
The point of tickEvent()
is to run something on every event loop iteration even if the screen doesn't need to be updated (such as in regular apps that refresh their window only on input events) because with the implicit event loop there's no other way to achieve that. But if you have your own event loop handling anyway, you can just call that code directly instead of implementing some virtual interface.
That should also answer your question about what to do for Application implementations that don't have a tickEvent()
. (Though, implementing tickEvent()
for GLFW at least would be nice too, but that'd need adding also setMinimalLoopPeriod()
and handling all possible interactions with draw and input events, and I don't want to force you to do all that work as well ;))
…ainLoopIteration#577
linked: mosra#577
This is awesome, thank you. I have no other comments, I'll get to merging this hopefully during the weekend. |
Sorry I forgot to remove the PR from draft. I might suggest other changes when working on my project ;). |
Split Sdl2Application mainLoopIteration in:
I did not split up the mainLoopIteration of the GlfwApplication/AbstractXApplication yet because the tickEvent isn't implemented in either of them.
Should I omit the mainLoopTickEvent() or implement the tickEvent() for the others applications with the same implementation as the one in Sdl2Application ?
Or either don't even split the mainLoopIteration ? (I didn't looked at their usages and therefore don't know if it might be usefull or not)
Linked: #577