Gdx.app.postRunnable latency under concurrent posting
0 reputation · 09 Feb 2020, 18:03 UTC
Symptom
Work enqueued through Gdx.app.postRunnable from multiple background threads may reach the application thread with variable delay. The goal is to characterize that scheduling latency without calling libgdx APIs off the render thread.
LibGDX confines most graphics, input, and asset calls to the application (GL) thread. postRunnable defers the enqueued runnable until the next render pass, so latency depends on frame duration and queue depth rather than a published real-time SLA. The framework does not document a deterministic maximum latency under concurrent load, and behavior may vary by libgdx version and backend such as LWJGL3, Android, or RoboVM/MOE.
Version assumption: a current stable libgdx release. A baseline would compare render-thread entry timestamps against queue depth across the targeted backends.
What is the expected maximum wait time for a posted runnable under concurrent posting from multiple threads?
Does latency scale proportionally with queue depth and posting-thread count on a given backend?
Which libgdx version and backend combination should serve as the baseline for this measurement?
