libRocket evaluation results
1,242 views
Skip to first unread message
"Lasse Öörni"
Dec 21, 2012, 10:23:10 AM12/21/12
to realxt...@googlegroups.com
As part of the realXtend core development end-of-the-year research, the
libRocket user interface library (http://librocket.com,
https://github.com/lloydw/libRocket) was experimentally integrated into
Tundra in the following branch
https://github.com/LudoCraft/Tundra/tree/librocket
to evaluate its features and performance. See the directory
src/Application/LibRocketPlugin for the plugin code. For now the build
scripts for the libRocket library itself are Windows-only.
libRocket uses a customized dialect of HTML/CSS to define the user
interface layouts. In addition to text elements and simple colored
backgrounds, it supports tiled background images, form controls
(button/radio/combobox/textfield input, scroll bars, sliders) and
representing data with grid or tree-like layouts.
libRocket requires the user to implement system (elapsed time and logging)
and rendering interfaces, and optionally file access. The rendering
interface draws the UI one drawcall at a time, basically 2D geometry with
UV coordinates and a texture. It also handles loading textures or
generating them from data supplied by libRocket.
A sample rendering interface provided for Ogre3D was usable with minor
adaptation. As libRocket requests textures for immediate use, it does not
directly fit in well with Tundra's Asset API concept, which may delay the
availability of an asset until it has actually been downloaded. In a
serious integration all UI layout and style files would have to be
manually preprocessed by Tundra to find out all the asset dependencies
beforehand, just like the Qt-based UI asset path does, but this was now
omitted for testing, and instead just local assets were used.
In addition to rendering and mouse/keyboard input injection, a basic
scripting interface (with a new entity-component, EC_RocketUiDocument) was
developed, which allows to query and adjust the positions and sizes of the
UI elements, as well as hook into button presses and input elements' value
changes. Using this interface, the AnimatedUi test scene was partially
replicated to measure performance, and is available in the directory
bin/scenes/RocketUiTest.
The "10 moving text labels" test can be seen in these images:
https://dl.dropbox.com/u/69662478/LibRocket_FloatingElements.jpg
https://dl.dropbox.com/u/69662478/QtUi_FloatingElements.jpg
The libRocket performance is a vast improvement over the Qt-based UI.
While the Qt UI-based test takes an average of 6.5 milliseconds per frame
(of which 4.7 ms is Qt CPU blitting) at 1920x1080, the LibRocket test
takes only 1.4 ms per frame (0.14 ms taken for UI draw call submission.)
This is almost a 5x speedup. The time taken per frame stays constant
independent of whether the UI elements move or not, instead the deciding
factor for performance is the amount of draw calls needed to render the
UI. Resizing UI elements seemed to carry a slight performance hit (about
0.1 ms per frame) which is likely due to libRocket re-layouting the UI.
libRocket was straightforward to compile and integrate, and its interfaces
and code are simple and robust compared to eg. CEGUI. The use of HTML/CSS
dialect instead of a custom UI definition language is a certain plus,
however the differences are still so significant that to see the result
properly requires using libRocket itself instead of just any HTML editor.
Outside of the project there exists a layout editor called Rockete
(https://github.com/FishingCactus/Rockete) but it was not evaluated for
now.
However, libRocket is not without its downsides and therefore can not be
unanimously recommended as a future Tundra UI solution, even though it is
a very strong contender.
Creating HTML-based layouts programmatically (eg. editor interfaces) can
be tedious; due to the HTML positioning and layout rules it is not always
straightforward to unambiguously know the position and size of an element,
compared to QWidgets.
The rendering interface only uses textures and geometry, and does not
allow to define custom shaders (the provided Ogre renderer just uses
fixed-function materials), therefore wasting some of the potential of a
GPU-based UI solution.
It seems (unless it is buried very deep in the documentation) that a
color/alpha modulation for elements or image backgrounds could not be
added by default, therefore making it impossible to do eg. smooth fades in
and out. This can be estimated to be fairly trivial to add using
libRocket's element decorators system.
Non-ASCII characters in input textfields did not seem to render at all
(libRocket uses FreeType for font rendering, which does support non-ASCII)
in either Tundra or the libRocket examples.
The rendering interface usage of libRocket is somewhat naive and
inefficient, as it does not seem to combine batches with similar textures
from several elements. For example rendering the 10 moving text labels
takes 20 drawcalls total, 10 for the backgrounds and 10 for the texts.
The search for the perfect GPU-based Tundra UI solution continues. In the
meanwhile, Merry Christmas and a productive New Year!
- Lasse
libRocket user interface library (http://librocket.com,
https://github.com/lloydw/libRocket) was experimentally integrated into
Tundra in the following branch
https://github.com/LudoCraft/Tundra/tree/librocket
to evaluate its features and performance. See the directory
src/Application/LibRocketPlugin for the plugin code. For now the build
scripts for the libRocket library itself are Windows-only.
libRocket uses a customized dialect of HTML/CSS to define the user
interface layouts. In addition to text elements and simple colored
backgrounds, it supports tiled background images, form controls
(button/radio/combobox/textfield input, scroll bars, sliders) and
representing data with grid or tree-like layouts.
libRocket requires the user to implement system (elapsed time and logging)
and rendering interfaces, and optionally file access. The rendering
interface draws the UI one drawcall at a time, basically 2D geometry with
UV coordinates and a texture. It also handles loading textures or
generating them from data supplied by libRocket.
A sample rendering interface provided for Ogre3D was usable with minor
adaptation. As libRocket requests textures for immediate use, it does not
directly fit in well with Tundra's Asset API concept, which may delay the
availability of an asset until it has actually been downloaded. In a
serious integration all UI layout and style files would have to be
manually preprocessed by Tundra to find out all the asset dependencies
beforehand, just like the Qt-based UI asset path does, but this was now
omitted for testing, and instead just local assets were used.
In addition to rendering and mouse/keyboard input injection, a basic
scripting interface (with a new entity-component, EC_RocketUiDocument) was
developed, which allows to query and adjust the positions and sizes of the
UI elements, as well as hook into button presses and input elements' value
changes. Using this interface, the AnimatedUi test scene was partially
replicated to measure performance, and is available in the directory
bin/scenes/RocketUiTest.
The "10 moving text labels" test can be seen in these images:
https://dl.dropbox.com/u/69662478/LibRocket_FloatingElements.jpg
https://dl.dropbox.com/u/69662478/QtUi_FloatingElements.jpg
The libRocket performance is a vast improvement over the Qt-based UI.
While the Qt UI-based test takes an average of 6.5 milliseconds per frame
(of which 4.7 ms is Qt CPU blitting) at 1920x1080, the LibRocket test
takes only 1.4 ms per frame (0.14 ms taken for UI draw call submission.)
This is almost a 5x speedup. The time taken per frame stays constant
independent of whether the UI elements move or not, instead the deciding
factor for performance is the amount of draw calls needed to render the
UI. Resizing UI elements seemed to carry a slight performance hit (about
0.1 ms per frame) which is likely due to libRocket re-layouting the UI.
libRocket was straightforward to compile and integrate, and its interfaces
and code are simple and robust compared to eg. CEGUI. The use of HTML/CSS
dialect instead of a custom UI definition language is a certain plus,
however the differences are still so significant that to see the result
properly requires using libRocket itself instead of just any HTML editor.
Outside of the project there exists a layout editor called Rockete
(https://github.com/FishingCactus/Rockete) but it was not evaluated for
now.
However, libRocket is not without its downsides and therefore can not be
unanimously recommended as a future Tundra UI solution, even though it is
a very strong contender.
Creating HTML-based layouts programmatically (eg. editor interfaces) can
be tedious; due to the HTML positioning and layout rules it is not always
straightforward to unambiguously know the position and size of an element,
compared to QWidgets.
The rendering interface only uses textures and geometry, and does not
allow to define custom shaders (the provided Ogre renderer just uses
fixed-function materials), therefore wasting some of the potential of a
GPU-based UI solution.
It seems (unless it is buried very deep in the documentation) that a
color/alpha modulation for elements or image backgrounds could not be
added by default, therefore making it impossible to do eg. smooth fades in
and out. This can be estimated to be fairly trivial to add using
libRocket's element decorators system.
Non-ASCII characters in input textfields did not seem to render at all
(libRocket uses FreeType for font rendering, which does support non-ASCII)
in either Tundra or the libRocket examples.
The rendering interface usage of libRocket is somewhat naive and
inefficient, as it does not seem to combine batches with similar textures
from several elements. For example rendering the 10 moving text labels
takes 20 drawcalls total, 10 for the backgrounds and 10 for the texts.
The search for the perfect GPU-based Tundra UI solution continues. In the
meanwhile, Merry Christmas and a productive New Year!
- Lasse
Peter C.
Dec 21, 2012, 8:45:19 PM12/21/12
to realxt...@googlegroups.com
It may be worth checking out Berkelium, Awesomium, and NoesisGUI as well.
- Lasse
--
http://groups.google.com/group/realxtend-dev
http://wiki.realxtend.org
http://dev.realxtend.org
Reply all
Reply to author
Forward
0 new messages