Posting lazy runnables
See original GitHub issueIf you call Gdx.app.postRunnable()
, all the backends also call Gdx.graphics.requestRendering()
(except Lwjgl3Application for some reason, and GwtApplication which doesn’t support non-continuous rendering).
If you’re using non-continuous rendering, this means you need to create your own solution for lazily doing something the next time rendering occurs, such as your own Runnable manager that is called at the beginning of render()
. If you have a multi-window application (or an Android live wallpaper / screen saver), then you can’t simply make this manager static either. You have to pass it around everywhere or do weird workarounds like this or this.
I ran into this problem because I was trying to set some things to be freed to pools at the end of the frame. But that triggers the next call to render()
, so everything is needlessly drawn again, and new items need to be returned to the pool again, and we now have a continuous rendering cycle.
So I’m proposing either:
-
Remove
Gdx.graphics.requestRendering()
calls from the backends that automatically call it when you post a runnable. This breaks current behavior, but it was already inconsistent behavior between backends. People using non-continuous rendering are probably a minority, but will probably also appreciate the extra control given by having the choice of whether a runnable should also trigger rendering. -
Add
Gdx.app.postLazyRunnable(Runnable runnable)
.
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (7 by maintainers)
Top GitHub Comments
I am in favor of solution 1.
Which one do you prefer btw?
You mean if we go for option 1, right?
Doing a where-used search in the library shows that it is used all over the place in the various backends, and usually in response to events where you would want to trigger a render when using non-continuous rendering.
That kind of makes me lean towards option 2 (and fixing the Lwjgl3 backend to behave correctly). Maybe I underestimated how often people would rely on this feature, since we’ve used it extensively in the backends.
If we went with option 1, we would need to carefully add manual calls to
requestRendering
almost everywhere libGDX callspostRunnable
.