Main loop processing order

XanHou

New Member
Contributor
Architecture
While running the game on my laptop in battery saving mode I noticed that the rendering took more than 50 ms, but the individual rendering tasks took each less than 3ms. The biggest time is in the synchronizing with the videocard. While the videocard is processing all the commands given to it by the rendering tasks, the cpu is sleeping.
Therefore I do not understand why the synchronizing (Display.update();Display.sync(60); ) is done after directly after the rendering commands (currentState.render(); ) are given to the GPU.
So I tried to put the rendering command before the updating of the game state and the display update after everything else. After some testing this does not seem to break anything, but does improve the framerate when the physics engine starts to take some time significantly, since in that same time the videocard is busy processing the rendering commands. An other way of doing this is simply swapping the render and display update commands without changing their location in the code.
On fast gaming rigs you would not notice this optimization (although it is a small optimization), but for anything with an integrated GPU this optimazation is vital.


Since this optimization is a very basic one, my question is:
Why is it not implemented yet? There must be some (good or bad) reason to it.

TLDR: Do processing of the game state between rendering and updating the display for better framerate.
Code:
//From:         
PerformanceMonitor.startActivity("Render");
    currentState.render();
    Display.update();
    Display.sync(60);
PerformanceMonitor.endActivity();
 
//To:
PerformanceMonitor.startActivity("Render");
    Display.update();
    Display.sync(60);
    currentState.render();
PerformanceMonitor.endActivity();
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
Hmm, the main side effect I can see is that input is polled on Display.update() as well, so a bit of input lag is introduced doing it before sync and render. But probably insignificant. Seems like a good improvement overall.

I imagine why it hasn't been implemented is
a) it isn't immediately obvious, or suggested by lwjgl doco that I can see.
b) there's a lot to do, and I at least am not focusing on optimisation at this time except where performance is impeding functionality (like the lighting algorithm). Should be noted that we are thinking of centralising lwjgl specific rendering code and migrating to libgdx.
c) Only You Can Save Mankind Stop Forest Fires Optimise Code
 
Top