Inherent frame delay?

[Wyverex42]

Hi,

I've noticed that when projecting a world position to screen and rendering a circle onto the ImGui background draw list at that position, that rendered circle will slightly lag behind when moving the camera.

I found that the plugin calls ImGui::Render just before calling ImGui::NewFrame in the same tick. That means all ImGui rendering will inherently be delayed by one tick since you only submit the render commands for the current tick in the next tick. Is there a reason why the plugin works this way? Could it be changed to submit render commands in the same tick?

Thanks!

[VesCodes]

This is due to a recent change to support standalone applications which don't go through the regular engine frame loop. I'll have to think about how to accommodate both flows but you can refer to the previous implementation that utilised FCoreDelegates::OnBeginFrame and FCoreDelegates::OnEndFrame that should fix this - see the changes to FImGuiContext in 054095b.

[Wyverex42]

Ah thanks, that makes sense. It's not super time critical, I can live with this issue for a while. So if you're going to fix it properly for both cases in the near future, I can happily wait for that :)

[Wyverex42]

There is another issue with the standalone application change. There is never a time now where you're not in an ImGui frame since EndFrame and BeginFrame are called back to back. That means it's not possible to e.g. add a new font because that's not allowed while in a frame.

To add a new font I'd now have to change FImGuiContext::Initialize and add it before the first BeginFrame is called.

[VesCodes]

Fixed in a973d76