Actorless UI
By default, the Prysm UI integration relies on Actors to tick the spawned Cohtml Views and System and to determine their lifetime.
In most scenarios that makes sense and makes the UI lifetime easily predictable, but can prove to be a problem when you want to preserve the UI state between changing levels, or when you want to have a separate UI thread in order to not stall the Game Thread where the game logic happens.
The FCohtmlViewWrapper is the class that is internally used in the Prysm plugin’s Actor-based integration inside the UCohtmlBaseComponent and the SCohtmlWidget to provide support for the UI inside the HUD, UMG and in-world UI. The FCohtmlViewWrapper however is neither an Actor, nor a Component.
Actorless UI approach
By creating a FCohtmlViewWrapper outside of the Prysm plugin, and using that to create and tick the View and System, we now have an “actorless” UI and this provides great flexibility. By using this approach, the interactions with the Cohtml Views and System can be moved on a dedicated thread, and keeping the UI state between level changes only requires the preservation of the FCohtmlViewWrapper.
UCohtmlBaseComponents and SCohtmlWidgets) with the “actorless” UI!What are the current limitations
Currently there is no out of the box handling of input, binding, and data-binding events. Blueprint integration is also not available, as it is part of the Actors that are normally wrapping the FCohtmlViewWrapper, but these missing features can be handled outside of the Prysm plugin.
cohtml::View and cohtml::IViewListener. Handling of these events should be done on the same thread where the View and System were created and if that was not the Game Thread, event buffering might be required.Example: Dedicated UI Thread
As an example of the flexibility this feature provides, you can check the ACoherentSampleDedicatedUIThreadHUD that shows how to spawn a dedicated thread and properly initialize the Prysm Library, System and View and tick them inside. It also provides a simple example on keeping the UI state between changing levels by caching and reusing the FCohtmlViewWrapper, used inside the ACoherentSampleDedicatedUIThreadHUD.
FCohtmlViewWrapper is used inside a dedicated thread, the UTextureRenderTarget2D* Texture that should be given to the View should be created ahead of time on the Game Thread.Inside the CoherentSample game you can find the DedicatedUIThread map, using the example ACoherentSampleDedicatedUIThreadHUD. This example shows:
- How to properly create a
Textureon the Game Thread; - How to create a
ViewWrapperandViewListenerinside the HUD; - How to provide the
ViewWrapperwith the createdTexture; - How to initialize, cache and reuse the
ViewWrapper; - How to create a dedicated thread and tick the View and System, and paint the View inside;
- How to resize the View when needed;
- How to draw the
TextureRT(filled by theViewWrapperPaint) to the canvas.