Discussion on future removal or rework of CEGUI::ColourRect

[Ident]

Discussion for the following news: http://cegui.org.uk/news/discussion-fut ... colourrect


I already made my points in the news. Feel free to discuss them here or add new arguments for or against ColourRect!

[KishukuOni]

I have always found ColourRect to be a little gimmicky. I think it looks cool and it's fun to play with, but I've never needed it.

[Ident]

I have always found ColourRect to be a little gimmicky. I think it looks cool and it's fun to play with, but I've never needed it.

Thanks for your input. I personally made a similar experience: It was "nice" and sometimes "fun" to try out, but it never actually fulfilled any purpose in any of my applications. However I am more of an engineer than a designer or artist, so maybe I got a limited viewpoint on this. I m looking forward to more comments.

[timotei]

I hate ColourRect and to me it looks like we can get rid of it I had too much trouble using it.

Btw, some L&Fs use it, what it's going to be replaced with?

[Ident]

I hate ColourRect and to me it looks like we can get rid of it I had too much trouble using it.

Btw, some L&Fs use it, what it's going to be replaced with?

I am not aware of any L&F that seriously uses it to its full extent (having a gradient of some sort, utilising all edge). Could you give an example please?

We can easily replace all ColourRect's with identical corner colours by a single colour. So, the general possibility to multiply a colour onto your widget, font or a part of the widget, wont be gone: The only thing that would be gone is the gradients.

[CrazyEddie]

If i remember right, windows look uses ColourRect for gradients.

[Ident]

If i remember right, windows look uses ColourRect for gradients.

Thanks for the input, CrazyEddie.
You are correct and I have actually not looked into this specific LNF yet.
As far as I see, in most cases the ColourRect gradients are applied to background imagery ("WindowsLook/Background"). For those I think we could do a simple substitution using one or multiple images. If one image with gradient doesnt suffice (in combination with a single multiplicative Colour) we could split this into two or three images. If I got it right, this should work.

At a lot of points in the LNF, the colours are also identical for all corners which means a single colour would do well enough there.
There is also a gradient used at a section called "gripper", and I think this could also be solved by a single colour and a "WindowsLook/VertScrollbarGrip" image that already has the gradient applied.

I havent tested such substitutions yet, so I could be wrong. What interests me here mainly is if we can do all these things 1:1 with simple edited image or edited-image+single-colour substituion. Can you think of a case where this wouldnt work ?

[CrazyEddie]

Yes, i'm pretty sure that the effects used for windows look could also be achived using imagery.

Probably the only effect you can't do with pre-rendered imagery is animation of the gradients, but as far as we know, nobody is doing that. And let's hope if there is anyone doing that, they let us know here

[Ident]

And the animation brings us back to the original issue - the performance drop that happens due to buffer regeneration.

The workaround mentioned in the news article I wrote might help to mitigate this performance issue.

Btw., is there a GUI toolkit / library / framework that has a similar feature as ColourRect?

[czuger]

Hello,

We use ColourRect heavily. It is used in many, many of the widgets we draw (its great for doing simple gradients). It is probably one of the most frequently set properties in our project

I have done a lot of profiling / optimization on CEGUI (and the rest of our project), since it has to run at 60fps on PS3 (which just doesn't have a lot to give in terms of PPU power).
The most dramatic offender of performance / memory consumption in CEGUI is the string based property system. When animating anything, there is *a lot* of scanf type functions running (to convert properties back and forth between string & non string representations). The CEGUI profile is utterly dominated by string parsing, no matter what is happening. I have modified CEGUI::String to store property values directly without converting them to string representations, to *massivley* speed up the entire system (animation and otherwise).

I have not found ColourRect to be that big of an offender of performance at all. Many things in CEGUI (at least the version we use, 0.79) trigger a regeneration of the vertex buffers. CEGUI provides an easy way to implement the render interface where these things can be taken care of if necessary.

In short, I strongly vote against removing ColourRect . If anyone is interested, I'd be happy to share the various optimizations I have done to get CEGUI to run fast (and fit into memory) on older hardware

[Ident]

@czuger Thanks your response, that changes quite a lot and shows that calling for a public discussion was a good idea

Regarding the property conversions: If I remember correctly, in 0.8 there have been a lot of improvements to the Property conversions. However, I think it still does convert the type at times so it could still be a performance issue - I have not encountered that on my performance check runs, but also I used the SampleBrowser which doesnt do more than some dozens of property sets per frame in the samples at most. I guess we should maybe add a demo, or modify an existing one, in order to simulate lots of changes happening per frame for such a purpose, if necessary. Also I wanted to mention that I am aware that the ColourRect feature isn't the primary cause of what's holding CEGUI back to be even faster than it is, I hope it didn't come across that way in my news article. It's only a big deal when it comes to CPU<->GPU related performance and i especially noticed the difference in certain specific situations and during performance profiling. On the pure CPU side there are and have been some way bigger performance slowdowns and we already worked on fixing a lot of them in the past. But since I mostly worked on Renderers lately, I focussed on how to optimise the last bits out of them.

To make us easier for us to understand the exact way how and where you use this feature: could you show us a screenshot of your application, on which the usage can be seen well, and maybe add one or two sentences of explanation how you use it? That would be very helpful to figure out if there is another way to achieve the same result in CEGUI or not.

Regarding your performance findings: It would be very helpful to know about these. Maybe you can create a thread to summarise them shortly. Of course we are mainly work on 1.0 (default branch) now, and a lot of things have changed already, but there is a good chance that a couple of performance slow-downs from 0.7.X still exist in default branch.

[Kulik]

We have gotten rid of a lot of string conversions in 0.8.x, I want to finally get rid of string storage in Animation keyframes in 1.0 but it hasn't been done yet.

I think these problems will get eradicated slowly but surely

[Bertram]

Hi there,

Btw, would the removal of it in favour of a "simple" coloring still be an impact on performances?
The solution was proposed in the main post, but here it doesn't seem clear some coloring system will be kept and at what cost.

Best regards,

[Ident]

All "ColourRects" would be replaced by "Colour". Which is equal to a ColourRect with identical Colour at all 4 corners. So no gradients. The performance cost is almost nothing.

[Ident]

@ czuger

Code: Select all

[13:49:49]   mpreisler   Ident: we have a safe setProperty<T>(..) in CEGUI 0.8 and default
[13:50:10]   mpreisler   if people really really have a need for speed we can add setPropertyUnsafe<T> which just reinterpret_casts the property class right away to save RTTI costs