Writing a renderFrame Function in a Typical PowerVR Framework Application

renderFrame contains updates such application logic updates, calculating and uploading transformation matrices, and rendering code

Generic

renderFrame gets executed by the shell once for each frame. This is where logic updates happen. In common scenarios, this may end up just being updates of uniforms, such as transformation matrices and updated animation bones.

OpenGL ES

In OpenGL ES, this function behaves as expected - running application logic and OpenGL ES commands as with any application with a per-frame main loop.
Note: Remember to call eglContext->swapBuffers() when rendering is finished or swap the buffers manually if not using PVRUtilsGles.

Vulkan

It is common to generate command buffers in renderFrame. However, it should be considered whether it is better to offload as much of this work as possible to either initView, so it is only done once, or to separate threads. It is preferable to generate CommandBuffers in other threads, for example, as objects move in and out of view. See the GnomeHorde example for this.

In all cases, it is highly recommended for command buffers to be submitted in this function, on the main thread. Otherwise, the synchronisation can quickly get unmanageable. There is nothing to be gained by offloading submissions to other threads, unless they are submissions to different queues than the one used for on screen display.

Remember: Submit the correct command buffer that corresponds to the current swapchain image using this->getSwapChainIndex().

Usually, renderFrame will be home to rather complex synchronisation. This is expected and normal with Vulkan development. See the SDK examples for recommended synchronisation schemes.

If application logic determines it is time to signal an exit, return pvr::Result::ExitRenderFrame instead of pvr::Result::Success, or call exitShell() from any function on the main thread.