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: http://cegui.org.uk/forum/viewtopic.php?f=7&t=6367
- 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: http://cegui.org.uk/forum/viewtopic.php?f=6&t=6863
Edit: Now with 100% more poll!