What is Coherent UI?

Coherent UI is a software development kit that allows game developers to create stunning user interfaces by using HTML5, CSS3 and JavaScript. Coherent UI empowers game developers with modern and easy to use technology, powerful tools and fast iteration and they can create great user experience for their games. Some of the games that use Coherent UI are Planetary Annihilation, War for the Overworld, Rust, Heavy Gear Assault. It is also used in several game add-ons such as the Curse Voice game client. Being a complete HTML5 renderer, Coherent UI provides an in-game browser and shop in several video games.

In this post, we will explain the architecture of Coherent UI and answer the questions some gamers had: – “What is CoherentUI_Host process?”, “Why do I have so many CoherentUI_Host processes?”

Coherent UI is based on the Chromium project. This is the same project that powers Google Chrome and it is using multi-process architecture. Coherent UI uses this architecture too and has two major components: the CoherentUI dynamic library that gets loaded into the game and the CoherentUI_Host application, which runs the various Coherent UI processes on the system.

There are three kinds of CoherentUI_Host processes:

1. Host – communicates with the game engine and the rest of CoherentUI_Host processes
2. Renderer – performs HTML5 layout, executes JavaScript, etc.
3. GPU – draws the HTML views on the GPU

Most games and applications using Coherent UI have one CoherentUI_Host running the Host process, one running the GPU process and one Renderer process for each view that their game is using. This makes for a total of 3 or 4 processes for most games and applications.
So why multi-process?

The multi-process architecture allows Coherent UI and the game to work entirely independently from one another. It allows the game to run while the UI is drawing or vice-versa. This way the game will never stutter just because some UI logic or drawing a specific widget took a little bit longer to execute. Having the game and Coherent UI working in parallel better utilizes the multiple CPUs or CPU cores that your system might have.

Independent processes use separate address spaces. Coherent UI leverages this and allows game developers to fully utilize the memory resources on the system. Having all the memory available for the user interface and/or the in-game browser in another process helps reducing the memory fragmentation and improving the memory layout of the game. This results in better performance for the game, better graphics, and smoother gameplay. This feature is especially important for 32 bit games. These games can access only 3GB (with a special flag, otherwise only 2GB) of memory, no matter that your system might have much more than that. Having Coherent UI running in separate address space allows game developers to use these 3GB for the game content and simulation. Аll the memory necessary for the user interface or the in-game browser is allocated in the CoherentUI_Host process.

Another advantage is that if any Renderer process crashes for some reason (usually due to faulty plugins), the game gets notified about this and restarts the process, allowing you to continue playing without having to restart the game.

Having separate processes for the user interface introduces also some difficulties. First, the processes need to communicate with each other. This communication has to be asynchronous, otherwise, we will lose some of the multi-process benefits. One of the drawbacks of the asynchronous communication is that introduces some delay between the game and the user interface. Coherent UI is using the most efficient APIs for interprocess communication on each platform, minimizing this delay, but still, there are situations where the delay is too high. Coherent UI also has Zero-Latency or (On-Demand) views (a view is a HTML page loaded in Coherent UI), which allow perfect synchronization between the game and the UI, despite that they run independently.

Coherent UI is using shared memory for resource loading

There is some memory overhead, but it is much less than what it seems at first. All modern operating systems virtualize the process memory and cache loaded shared libraries and executables. This means that there is only one CoherentUI_Host image loaded in the memory and all the CoherentUI_Host processes are sharing it. Some operating systems even share the memory between parent and child processes, further reducing the actually used amount of memory. To avoid having multiple copies of resources and having to actually copy them, Coherent UI is using shared memory for resource loading. This means that when Coherent UI needs to load some resource, say a picture, the game reads the picture into a shared memory segment and Coherent UI reads the picture from the same memory segment avoiding any copying of the resources. Of course, there is some overhead that we can’t avoid – such as the double buffering of the views. Although it increases the memory necessary for the UI, it allows Coherent UI to draw the next frame of the UI while the game is using the current one and reduces any perceivable delay.

VMMap showing the memory usage of CoherentUI_Host. Note that only 15 MB are actually used by the process and 11 MB can be shared with another CoherentUI_Host.

There are some drawbacks of the multi-process architecture like context switching – the process of the switching from running one process to running another. This is how computers work, so it can’t be fixed. Also, consoles and mobile devices don’t allow multiple processes for games. This led us to develop a new technology codenamed Coherent UI GT. Coherent UI GT runs inside the game process and will provide fully synchronous API to the game developers.

The multi-process architecture gives a lot to Coherent UI and it is one of its key features. It is working great for the millions of gamers playing Coherent UI powered games. I hope I have answered most of your questions about the CoherentUI_Host process and explained how Coherent UI works.

It you are interested in technical analysis of multi-process architectures and how Chromium works, here are some interesting links:
http://aseigo.blogspot.com/2014/07/multi-process-architectures-rock.html
http://aseigo.blogspot.com/2014/07/multi-process-architectures-suck.html

http://www.chromium.org/developers/design-documents/multi-process-architecture