Enabling Direct WebGL in Qt Quick 2

pasi.keranen's picture

Pasi Keränen
Pasi Keränen
The Qt Company
Europe Date: 
Wednesday, October 8, 2014 -
9:00am to 10:00am
Europe Room: 
C1
Europe Track: 

Presenter Bio: 

Pasi Keränen has been working with 3D related software since 1990's from applications running on top of OpenGL, optimisation of mobile UI frameworks to run on top of hardware accelerated graphics, down to working as architect and technology owner in mobile graphics adaptation area. Pasi has participated Khronos Group standardization (EGL 1.4, OpenKODE 1.0) and chaired the Khronos OpenWF API working group between 2008 and 2009. Today he works at Digia Finland as Software Specialist in the Qt Research & Development organisation on graphics technology related matters.

Abstract: 

WebGL 1.0 API standard from Khronos Group defines a low level, state based 3D rendering API. It is very similar to OpenGL ES 2.0 and enables access from JavaScript code to the hardware graphics accelerator or graphics processing unit (GPU).

Qt WebView and Qt WebEngine support WebGL as part of HTML rendering and can be added to your Qt Quick scene to load HTML content that uses WebGL API and run the content that way. This approach is a bit heavy from the rendering point of view, as the 3D content must be first rendered as part of the HTML content rendering to an off-screen buffer that is then composed together with the rest of the QML content.

As Qt Quick scene graph is built to be accelerated efficiently with hardware acceleration provided by the GPU, the idea of enabling programmers to use WebGL API to directly render their 3D content from Qt Quick JavaScript and then use Qt Quick for the 2D UI content came about. This presentation gives an overview of Canvas3D implementation that enables this.

There is a paradigm difference between WebGL and Qt Quick that makes the integration between the two a bit challenging, Qt Quick is based on the paradigm of describing the UI scene once in QML, translating that description to native bindings and elements that can then be efficiently rendered by the scene graph rendering engine. Where as WebGL is built on the paradigm of having to manually call all the required low level rendering functions every frame, repeatedly. This presentation describes how the Canvas3D implementation merges these two paradigms by hooking to the Qt Quick Scene Graph’s rendering loop and then calling the JavaScript rendering code once per frame on the main thread to avoid multithreading issues in JavaScript code.

The low level nature of the WebGL API means the code running on top of the API has a lot of flexibility in how it uses the functionality being offered by the API. This flexibility comes with a cost in complexity; drawing even a simple 3D scene requires quite a bit of code to be written to load a 3D object from file, parse it to format that can be passed through WebGL to the GPU. In many simple use cases it is actually more efficient to use a library such as e.g. Three.JS, SceneJS or CopperLicht to handle most of the low level details of 3D scene rendering and instead concentrate on creating the required user experience on top of them. Today there is a lot of activity around different 3D engines that run on top of WebGL in HTML and the related tooling.

A port of the Three.JS library has been done as part of the Canvas3D implementation and this presentation briefly goes over the needed changes, why they are needed and potential future developments to make the porting easier in the future.