Discussion on future removal or rework of CEGUI::ColourRect (NOW WITH POLL!!!)

Not too long ago there has been a great addition to CEGUI: The Animation feature done by Martin. This feature revealed a performance issue for CEGUI windows: Animating a ColourRect property will trigger a reconstruction of the entire GeometryBuffer's vertices. The data of each vertex has to be recalculated to match the new ColourRect. The creation on the CPU and the uploading to the GPU of those vertices creates quite a performance impact. This situation could of course be improved by more complex measurements, such as double-buffering our vertices. This works the way that we mirror the buffers and use one for reading and one for writing for each frame, and swap them whenever we need to update a buffer on the GPU. This would solve at least the data transfer problem and help a lot, but it would effectively double the GPU data used and the CPU load would still be there. Using non-interleaving GPU data would be another way to do it but that is also not a solution free of downsides.

The first thought we had was trying to replace this functionality using shaders (which would of course not work with fixed function pipeline). However, I quickly came to the conclusion that this is not feasible. The data is per-vertex and can't be easily simulated. A global (uniform) value would work, but that cannot reflect per-vertex behaviour unless using complex tricks. When I told Martin this he agreed. However after thinking about it again I thought of a workaround: Each vertex would have to have an attribute added (for example represented by 1 byte) which stands for the corner (e.g. left top = 0). The colours would be provided as a array of 4 vec4's in the OpenGL shader (and analogously as float4's in the Direct3D shaders). Using the ID of the vertex attribute, the right colour can be accessed. This would in total require uploading 16 floats for each window (unless the last 16 were equivalent), equivalent to the size of a matrix. Also it would require adding 1 byte (this might end up taking more space in reality due to padding/alignment) to the vertex data to provide a fixed ID. The geometry would not have to be regenerated again this way.

The other way would be to remove ColourRect entirely and just offer Colour in the future. This is where we would like to invite everyone for discussion to give reasons why ColourRect should be retained.

Reasons I see for removing it:
- For widgets/windows, the ColourRect changes the overall look of the window in a quite "unpredictable" (as compared to what you can do in image editors) way, basically creating a multiplicative gradient of colours over it. In my opinion, instead of relying on this, users should simply be using different imagery for the widget.
- For Font this does the same thing: applying a quite "unpredictable" but simple linear gradient over text. This might sometimes be nice to have, but most likely, just for windows, it won't be useful. If users want fancy Fonts, they have the functionality of Bitmap Fonts in CEGUI, allowing them to create all letters in whatever exact way they want them to look, and save them as imageset.
At this point I want to remind users of Zadirion's CEGUI Font Exporter for Font Studio:
- This would allow us to easily remove it boosting both CPU and GPU performance in CEGUI especially during animation, and simplifying CEGUI further.

Reasons for keeping it:
- It is always bad to remove a feature and better to find a way to keep it
- Someone could be relying this heavily (please inform us then, this is the time!)

Please join our forums and discuss with us:
Edit: Now with 100% more poll!

Multi-process building enabled for Visual Studio

For all future Releases and all current branches (v0, v0-8, default branch) the /MP option for building multiple processes has now been enabled. This means that CEGUI will build faster if multiple cores/hyperthreading threads are available.
According to our research and experience there shouldn't be any issues with VS 2005, 2008, 2010, 2012 and 2013. I personally tested the changes with VS 2008 and 2010 and 2013 was tested by another team member. In all tested versions, the multi-process build setting worked as expected using all available cores/threads, even in the aged Visual Studio 2008 (with SP1).

As always, if anyone sees any issues that could arise due to this change, please inform us about it in the forums or by chatting with us in our IRC channel.

Below i added a screenshot from VS 2010 building CEGUI with the added /MP flag in usage. CPU is a Quad-Core with Hyperthreading, all threads are used which leads to almost 100% CPU Usage. The CEGUI team stands united in the belief that this screenshot will amaze absolutely everyone.


0.8.4 Release broke ABI & API compatibility

In utter shame I have to admit that amidst of hundreds of changes from version 0.8.3, there has been one change which caused an ABI and API break. In case you rely on ABI and API compatibility, you are advised to skip this Release and use the upcoming 0.8.5 Release or downgrade to 0.8.3. In order to prevent this from happening again, we increased goat and leprechaun sacrifices by 78%.

For further information:
The following symbol is the one that was accidentally removed by a person who is from Austria and likes mustard. I will not name him!

CEGUI::S_parentIdentifier [data]
[symbol: _ZN5CEGUI18S_parentIdentifierE]

We will readd it in 0.8.5 to avoid breakage. 0.8.3 -> 0.8.5 will be compatible, this issue will only ever apply to 0.8.4.

CEED 0.8.0

The first stable release of CEED has been released. Archives provide testing sample data with CEGUI 0.7 and CEGUI 0.8 datafiles.

There have been 11 tickets resolved compared to the last snapshot11. Most of the tickets are bug fixing and stabilising changes.

Grab the source tarball, Windows standalone binaries or Windows installer. The MacOS X app bundle will come later:

We have decided to name the CEED releases according to which CEGUI the release is based on. CEED 0.8.x will work with all CEGUI 0.8.x releases. CEED has a stable branch called v0-8 that serves a similar purpose as CEGUI v0-8.


- 0001035: [General] CEED should put /usr/lib64/python2.7/cegui-X.Y into PYTHONPATH (Kulik) - resolved.
- 0000930: [General] Explicitly check FBO support and report if it's not there (Kulik) - resolved.
- 0001020: [Layout editing] Feature: Strip all comma values from all absolute position and size values - Add button that prevents this while moving/resizing (Ident) - resolved.
- 0000969: [CLI tools] Whenever anything fails in ceed-mic the tool is stuck forever (Kulik) - resolved.
- 0000943: [Layout editing] Preserve expanded/collapsed when dragndropping/reparenting widgets (Kulik) - resolved.
- 0000951: [Compatibility layers] Error when migrating looknfeel (Kulik) - resolved.
- 0000940: [General] Changing shortcuts of actions with no default shortcut fails (Kulik) - resolved.
- 0000939: [Layout editing] Recursive lock/unlock of widgets in layout editing (Kulik) - resolved.
- 0000897: [Imageset editing] Editing GUI for per-image autoScaled and native{Horz,Vert}Res (Kulik) - resolved.
- 0000569: [General] Dock widget resize handles are super small (OSX) (Kulik) - closed.
- 0000497: [General] Help API + the ability to declare which help sources are relevant to which functionality (Kulik) - closed.


CEGUI 0.8.4

Patch release from v0-8 branch - It contains many minor fixes and changes. You can use the following links:

Source Package Downloads:
Source code packaged a a .zip file
Source code packaged as a .tar.bz2 file

Documentation Downloads:
Documentation packaged as a .zip file
Documentation packaged as a .tar.bz2 file

Dependencies (Windows / Apple OS X Only):

Or click here for the online version of the docs


- Package 'promo' dir, people might want to use logo in their products.
- FIX: Static linking issues. See new CEGUI_BUILD_STATIC_FACTORY_MODULE option.
- FIX: I broke the CMake before by omitting an endif()
- MOD: docu was a bit unclear
- MOD/ADD: if samples browser is compiled in debug mode, the mouse can now leave the window. if it comes back into the render window, its position will be set properly and won't be set to the centre of the window.
- MOD: Fixing ouput message for Ogre if OIS wasnt found - fix by Henri Hyyryläinen
- MOD: SamplesBrowser can now be closed by clicking the 'X' on windows when using OGL(3) renderer
- Added a note about changing default image to getMouseCursor
- Fixed issue #1031
- MOD/FIX: Changing the mentions of "True" and "False" to the xsd:boolean conform
- MOD: Adding if-cases to prevent divisions by zero from occuring and handling it
- FIX: Making looknfeel files xsd::boolean conform by replacing True by true
- MOD: Adding top-level target dependencies for the samplebrowser
- MOD: Removing the "filename:" info from all license headers
- REM: Removing some ultra-vintaged empty files
- MOD: Fixing the docu
- MOD: Extending the hgeol file
- MOD: Fixing the doxygen docu for releases, linking to our website now instead
- Fix compilation on MinGW
- MOD: Removing redundant xml ban that used to cause a warning about HorzExtent
- MOD: Adding <algorithm> as include for all compilers and modifying include order
- Moved readme to ./ where bitbucket will pick it up
- DirectFB is not supported, let us say so in the cmake option description
- FIX: Fixed an issue in the Samples that is only popping up when using VS2008
- MOD: Replacing last strings in the XMLHandler to replace them with static getter
- MOD: Changing serialisation order of elements to make it more intuitive to read
- MOD: Adding widgetComponent default and adjusting serialisation
- FIX: Fixed directive in merged pull request
- MOD: Fixed order of serialised output
- MOD: Fixing the default value comparison
- MOD: Added a getter to FormattingSetting, added default values
- ADD/MOD: Broad refactoring and general fixes of Falagard serialisation
- FIX: Fixing comments, calling write attribute function correctly
- MOD: Changing local variable to const
- MOD: Fixing assert issues on MSVC in glm when a 0-sized window is used
- MOD: Fixing qualifiers for GCC and other compilers - this time for real!
- MOD: Fixing qualifier for GCC and other compilers
- MOD: Fixing serialisation output in an ABI-compatible way for v0-8
- MOD: Default value for "help" attribute in Fal
- MOD: Changed the serialisation of attribute "inherits" if not inheriting
- MOD: Added a const default value string for the help value to replace the hard
- MOD: Added helper functions for WidgetLook XML serialisation to be used in CEED
- Fixed up CEGUI.pc - include dir is /usr/include/cegui-0
- FIX: switch to 'if test' syntax from 'if [' for shell commands (cmake issues)
- Fixed Bug when not registering Root Namespace
- Added LuaDoc export to tolua++ bin
- Changes required to expose Falagard related iterators in PyCEGUI
- Hidden "getMouseCursor() const" from GUIContext in PyCEGUI
- Tweak the perform-cppcheck script
- Enhance perform-cppcheck script
- Fixed FSF address in datafiles/fonts/LicenseGPL.txt
- We need to install PyCEGUI into the platform specific python site-packages
- Use utf-8 in doc/README
- MOD: Fixed broken SampleBrowser build for several Renderers
- Fixed a copy-paste error in ScrolledContainer
- Complete initialization of Ogre::LayerBlendModeEx objects.
- FindLua51: Also look for lua.h in the "lua-5.1" directory.
- Fix build with >=freetype-2.5.1 wrt #1007
- REMOVE: StringEncoder license stuff
- MOD: Fixed samplebrowser crash on exit during load-phase and minimal refactoring
- MOD: CMAKE - Added .inl files to the projects, formerly they werent added
- FIX: DirectFB default off in CMAKE
- FIX: Fixing the content area calculation in the case of Center aligned windows
- MOD: Fixing Spinner window text update on value change
- MOD: Default options in CMake changed to the actual default values we agreed on
- MOD: Moving CMake Sample dependency check
- MOD: Added SampleBrowser dependency checks and default Sample on/off checks
- MOD: Adapting code files for CMAKE CEGUI_SAMPLES_USES* changes
- MOD: Preparing CMAKE for CEGUI_SAMPLES_USE_* removal
- MOD: case sensitivity related bug in cmake
- FIX: Adding includes required for deletion of instances and using OGRE_DELETE
- MOD: OgreRenderer modified to support the latest Ogre default branch
- FIX: Ogre getFixedPipelineEnabled() not defined without RTS, removed build issue
- Solved compile error with Python bindings, due to some Ogre classes declaration (v0-8, 4-space-tabs).
- FIX: Undeclared function would be called in case of no RTS built for Ogre
- A) fixed new CMAKE policy CMP0045 issue in CMakeLists.txt. This feature was introduced recently in this commit: ... Bb) fixed CMAKE problem with cmake/CEGUIMacros.cmake when including the project with ExternalProject_Add() CMAKE feature in a project. I had to escape the '[' and ']' characters because in this way CMAKE was not recognizing those characters. CMAKE version: 2.8.12.
- MOD: Fixed VS2013 compile error - thanks to JKnife
- Backed out 209e31f: MOD: Changing DefaultWindow maximum size
- Fixed Console.wnd, previously it was an invalid layout (a mix between 0.8 layout and 0.7 layout)
- MOD: Changing DefaultWindow maximum size
- ADD: Added visual studio templates that are used for proj settings of samples
- Fix the CMP0022 policy on CMake 2.8.12+
- FIX: Fixed a typo that caused a compile error, good job me! good job.
- MOD: Tiny change to Ogre thread provider effects on cmake and comment to it
- FIX: Fixing ogre cmake for the case that no threading provider is used
- MOD: Fixing messed up warning message, fixing default window size in Ogre D3D
- MOD: Forgot to add declarations for OgreTexture changes
- MOD: Forgot header for OgreBaseRenderer changes
- MOD: Changed blitting behaviour of texture and minor fixes
- MOD: Fixed shader related issues, added OGL3.2+ glsl shaders, made it GL3 ready
- MOD: Added default config options for Ogre Samples and visible mouse in debug
- Fixed a build error in falagard/TextComponent when BIDI support is enabled
- MOD: Fixed a bug that made OgreRenderer link to the Ogre release lib always
- MOD: Added the possibility to find OIS if stored as Ogre dependency
- Fixed minor typo in docs neglecting CEGUI namespace.


Improvements to our documentation infrastructure

  • The "missing text in diagrams in API reference" issue was finally solved. Diagrams now work everywhere, including the 0.7.9 and 0.8.3 docs.
  • We have converted our README files to markdown syntax. Bitbucket now shows helpful overview content on our CEGUI and CEED repos.
  • Our official documentation landing page at was greatly improved. (kudos goes to Timotei for web design)
  • The version switcher in API docs can now handle fragment components in URIs. You should no longer see any "Invalid request" fatal errors when switching versions.

We hope that you appreciate our continuing effort to improve our documentation and the infrastructure surrounding it.

Current developments in CEGUI and CEED

GSoC 2014 has started and timotei and me (Ident) have both been accepted with our projects. Timotei will work on the internals of CEGUI and rework important parts of it to adhere to the Model-View pattern. Read the short description here. I will work on CEED to add an Editor for Look n' Feel files of CEGUI. The editor should make it a lot easier for CEGUI users to skin widgets, which previously had to be done in XML exclusively. Read the short description: here.

Timotei already made good progress and I already added a new feature to the CEGUI Layout editor and started working on the editor for editing WidgetLook properties. Additionally the CEGUI team is always working on bug fixes and the next minor release (0.8.4 based on v0-8 branch) should be coming soon.

In our unstable CEGUI default branch, the OgreRenderer and IrrlichtRenderer are still broken currently after my changes during last summer's Google Summer of Code. However the Direct3D11Renderer has already been completely redone and contains some important improvements compared to the previous versions of the Renderer (see previous news). The OpenGL and OpenGL3 Renderers in default branch are functional. In the little time we have, the CEGUI team is also trying to get the IrrlichtRenderer and OgreRenderer updated to work with the general CEGUI Renderer changes, this might still take a while though. As always, we recommend the v0-8 branch for stable development.

CEGUI C# port: SharpCEGui

We want to announce that there is a "quite new" (1 year old, but we hadn't discovered it until now) C# port of CEGUI called SharpCEGui available on bitbucket:

Upon asking about the functionality, one of its developers replied to me that it  in a good shape and can be used:
"Well the port it's in good state (there are some NotImplementedExceptions) but most of the samples are working.(the animation sample it's not ported) I have ported almost all the codebase of the original library except the new commits that You have made with the svg support and the commits of timotei for the new input handling but I will (lack of time)."

The developers are part of the company Icehole Games (, if you want to check them out.

We haven't personally tried the port out but it looks very promising. If you have tried it out and want to tell us how it is, then feel free to discuss the port in our CEGUI forums.

Created new backwards-compatible Direct3D11 Renderer in default branch - replaces all existing Direct3D Renderers

After some fundamental changes and overall refactoring of the rendering system of CEGUI during my last year's GSOC 2013, it was necessary to update all Renderers. Only the OpenGL and OpenGL3 Renderers were functional during the Google Summer of Code in my development branch. Afterwards I started working on the existing CEGUI Direct3D11 Renderer (which was not written by any core members) on the default branch of CEGUI and looked for general improvements of it. As previously announced in the forum I planned on removing the Direct 3D9 and Direct3D 10 Renderers. This decision was made after an excessive discussion with user "SomeDude". When I started working on the Direct3D Renderers I noticed that they contain a lot of boilerplate code and also I was very unhappy with the Effects library. A solution for this would have been to create our own Effects library which would solve a lot of issues for users. However, I realised I do not even need this and can just work with the low-level Direct3D commands and build up a similar setup as I have in the OpenGL Renderers. In the end I had a fully functional Renderer without any extra dependencies, light-weight and effective and also it is backwards compatible to Direct3D9 and Direct3D10. This means that although we only have the Direct3D11 Renderer in the default branch, we still fully support older hardware! The only downside is that you need to have Direct3D11 installed which is only possible on Windows Vista or higher. However, since the Windows' XP support officially ran out a while ago, we don't expect to have any XP users once CEGUI default branch will be released as the next major version of CEGUI - therefore we don't expect any issues. And we won't need the annoying Effects library in the future anymore, which could have potentially broken our setup in the future, and which users often had difficulties with!

TLDR: I removed D3D10 and D3D9 from default branch and made D3D11 backwards compatible up to feature set 9_1 ( "ps_4_0_level_9_1" and "vs_4_0_level_9_1" ). As a side-note: at this feature-set the max tex size (width and height) is 2048 so an imageset loaded may not be bigger than that. 9_3 allows up to 4096, so that works with all our current datafiles. CEGUI hardware support stays unchanged this way, but the Direct3D11 Renderer is required therefore Vista or higher is necessary.

- Lukas M. (Ident)

GSoC 2014

Once again Worldforge has had the good fortune to be selected as a mentoring organization for Google Summer of Code 2014! CEGUI will participate under the Worldforge umbrella as we had for the past 2 years.

This is an awesome opportunity for students to both get more involved in the project as well as get a sweet gig for the summer. If you’re a student reading this, waste no time getting over to the GSoC site and read up on how all of this works. You can then visit the Ideas page and see if any of our project ideas suits you.

Feel free to contact us for more details. Our IRC channel is called #cegui and runs on Alternativelly, you can use email: team at to reach the team.

(This blog post is a rip-off of Erik's writeup at