Because of the asynchronous nature of Coherent UI there is some lag between the game and the UI. If the game is running with 60 fps and doing Coherent::UI::ViewContext::FetchSurfaces
on every frame this lag won't be noticeable by the user. However in order to minimize this, it is advisable to trigger all events that effectively change the view and call Coherent::UI::ViewContext::Update
as early as possible in the frame and perform Coherent::UI::ViewContext::FetchSurfaces
as later as possible, just before drawing the view in the client application. This way there is a great chance that the necessary redrawing of the view will have happened and will allow any changes to be visible in the same frame with no lag whatsoever. Such a goal should be easily achievable as view rendering usually takes a fraction of the time compared to a full game frame.
Coherent UI rendering is performed out of your game's process. This allows the game to run smoothly no matter how complicated the UI is. However if the game has occupied all resources of the GPU it may happen that Coherent UI does not receive enough GPU time degrading its performance. It is important to leave some GPU resources to Coherent UI in order to be sure that the UI will run smoothly. Some experimentation might be required in order to balance the the resources according to the needs of the application and how complicated the CoherentUI views are.
If GPU resources are really tight you might consider using pure software rendered views. Especially if you have relatively simple content in your page, limited GPU resources available and use shared memory - the software path is probably a good way to go. It is enabled per-view by setting the "ForceSoftwareRendering" flag to true in the ViewInfo structure on View creation. You can freely mix hardware and software views created by the same ViewContext. Note that they are not compatible with on-demand and time control. 3D CSS transformations and WebGL will also not work in them.