Technical Overview

At a high-level Cohtml does the following things to render your UI:

• Load and parse HTML files.
• Build a DOM of the page.
• Load and parse CSS styles. Styling allows for having very rich interfaces with a complex layout and visuals.
• Load image files and fonts.
  • Images should use premultiplied alpha for correct display
    • It is recommended to use DirectXTex/texconv for converting DDS files.
    • The correct command line for texconv includes the “-dx10” and “-pmalpha” arguments, for example texconv.exe -ft dds -pmalpha -f BC7_UNORM -dx10 input.png
• Load and execute JavaScript code. JavaScript is used to code more advanced logic for the user interface.
• Communicate with the client application to send/receive commands or input.
• Render the page in a texture. Cohtml uses Renoir - Coherent Labs' internal rendering library that draws the page in a texture that can be used by the client application.

In Gameface terms, a page along with its styles, DOM and JS code is called a CohtmlView component . You can have as many Views as you need in your application.

Cohtml has an advanced task-based architecture that tries to make the best use of all cores and computational power of the device while saving battery at the same time. Key technical features of Cohtml include:

• Task-based architecture. Many operations in Cohtml run on worker threads, which improves scalability, overall performance and battery duration.
• Data-oriented design. Internally Cohtml owes much of its performance to a modern data-oriented design.
• High-performance rendering with advanced batching. An additional performance boost is given by the fact that only changed parts of a page are re-drawn each frame - not the whole UI.
• Asynchronous resource loading. All resources are loaded in worker threads so that the main UI thread doesn’t get stalled.
• Full control over memory allocations, file loading, logging and rendering. Users can control how memory and files are loaded. Custom rendering backends can be easily developed with the provided interfaces.
• Support for iOS, Android, Windows, PlayStation 4, Xbox One, UWP and Mac OS X and Linux.

Multithreading #

Key to the scalability and performance of Cohtml is its multithreaded architecture. At the moment Cohtml designates a “Main” or “UI” thread. This is the thread where the user has to interact with the UI logic - send events, input and execute JavaScript. All of the View’s methods should be called on that thread. The other thread on which the user interacts with Cohtml is the “render” thread. This is usually the thread that submits commands to the GPU. On that thread, the methods of the ViewRenderer should be called which will, in turn, execute the necessary rendering commands. Additional work includes View resource loading, View Layout, JavaScript garbage collection, etc. All these operations must be scheduled by the user on worker threads, or dedicated threads should be created to handle those tasks.

Cohtml will not create threads behind the scenes as they might interfere with the workload of the application.

The different work “channels” are:

• Main (UI): holds the DOM and executes the JavaScript code. The user submits input and sends events to the UI in this thread. This is the thread on which cohtml.Library.CreateLibrary was called. Often this is also the “main” thread of the application.
• Render thread: the ViewRenderer methods are called on this thread. It should have access to the rendering subsystem and the rendering commands will be executed on it. This is usually the render thread of the application. It can change, but you can only execute one “Paint” concurrently.
• N Worker threads & Layout threads: Cohtml generates work for worker threads for many activities including resource loading; parsing, layout etc. The Layout operation can also happen on the Main thread in the cohtml.Net.View.Advance method. This is controlled by the cohtml.Net.LibraryParamsWithExternalRenderingLibrary.UseDedicatedLayoutThread flag. The Layout is a heavy operation and it’s strongly recommended to let it happen on a worker thread. Using a layout thread is highly recommended as it will significantly reduce the cohtml.Net.View.Advance time and improve scalability.

Worker threads execute Resources and Layout tasks. Resources tasks are global for all Cohtml Views, as they share the image loading and caching, parsing etc. resources. However, the Layout tasks can be scheduled per View. This allows better scalability and having a separate thread per View Layout is thus possible, although not recommended.

It’s possible for Layout tasks to depend on resources, hence not executing Resources tasks can lead to delays of the Layout tasks, which can potentially lead to blocking on the next frame until the previous Layout completes. For example, text layout depends on font glyph data. Because fonts are loaded partially in Cohtml, cohtml.Net.View.Advance can schedule tasks for loading specific glyph data from registered fonts. Layout tasks will be scheduled only after glyph loading tasks are complete. This is required for each new glyph in the document to properly layout elements on a page.