Discussion on future removal or rework of CEGUI::ColourRect

[Kulik]

Just a note to my suggestion that Ident pasted here.

The big downside of this solution is that if you do things wrong it will explode in ways that are hard to explain. You will inevitably interpret memory as something else and create fascinating weird effects. I am pretty sure we would have swarms of people posting strange backtraces if we add this method. So not sure if it's worth it.

Perhaps if it's guarded with CEGUI_ENABLE_UNSAFE_PROPERTY_SET_GET and we document that you acknowledge that you can not make any mistakes when handling properties or shit will explode.

We need a performance test comparing string property set/get vs safe typed property set/get vs unsafe typed property set/get. Then we may be able to judge the benefits.

EDIT:

Code: Select all

3: Running performance test PropertySet String set test...
3:  0.551895s wall, 0.550000s user + 0.000000s system = 0.550000s CPU (99.7%)
3: Running performance test PropertySet typed set test...
3:  0.050000s wall, 0.050000s user + 0.000000s system = 0.050000s CPU (100.0%)


Typed property set with UVector2 is roughly 10x faster than string based. This is with all the type safeties.

[Ident]

I am still hoping for examples of usage in form of datafiles or screenshots. Would help a lot to understand how it is being used.

[Bertram]

Hi there,

I'm doing a bump just to know. What was decided or maybe implemented/changed so far?

best regards,

[Ident]

Hi there,

I'm doing a bump just to know. What was decided or maybe implemented/changed so far?

best regards,

After asking him directly, Czuger sent me a quite long mail about his view.

I haven't decided for sure but most likely we will retain full compatibility for this feature by adding a per-vertex attribute solution using uniform variables, which should allow us to keep the whole thing at good performance. It seems like some people want to use this feature and czuger made a good point saying that it is always bad to cut out long-existing features.

Once I find time I will implement a test-solution in OpenGL 3 and see if the per-vertex solution introduces a performance drawback: I have to see if the uniform updates have any noticable effect. If it runs with minimal changes I will go on to implement the same solution in D3D and Ogre, If it doesn't then I m not yet sure what to do about the whole issue.

[Mikademus]

Hello people, long time no see. It feels good to be back and I am extremely happy to see so much good progress has been made and that CEGUI is in good hands!

In my opinion, instead of relying on this, users should simply be using different imagery for the widget.

(my boldface)

Reacting to the bolded part of the quote I would just like to point out that as developers, especially C++ developers, we should never impose limitations on how the users may express themselves though the tools we provide; we may know the library code we produce better than anyone else but we don't know all ways much less the best way for clients to put our code to use. UI is in its nature about allowing maximal freedom of expression, and this should be reflected both in the facilities offered but also in how we think about our users.

Less ideologically but related to this: colour gradients are a very powerful tools to provide UI effects in addition to as well as without changes in the bitmap data and as such is a highly meaningful functionality to retain. The rework as you are currently envisioning it entails approx. 16 floats. If the alternative is alternative bitmaps, then that entails much more memory overhead even for the smallest widgets than the 64 bytes 16 floats would occupy (assuming a 32-bit platform).

Lastly, the ColourRect:s are part of the established API and set of features since the earliest versions of CEGUI and that is a third reason to retain them. I am not saying that all things ancestral must be retained out of reverence, but I am saying that what is a core-level albeit seldom used feature should definitely be retained.

Now I will read the entire thread and see to what extent everything I said has already been stated! <-- I've missed this emoticon


Edit, having read the thread now:

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.

The preferred solution would of course be to allow the user to in some what select which model to use: a simpler uniform colour with less overhead or a more advanced four-corner gradient with a cost associated. Again along the C++ ideal: as far as possible allow the user the choice and avoid charging for what is not used. I have forgotten the underlying structures so I don't know if this is achievable, but I thought I should mention this as something to consider.

[Ident]

Hello people, long time no see. It feels good to be back and I am extremely happy to see so much good progress has been made and that CEGUI is in good hands!

Good to have you back.

Less ideologically but related to this: colour gradients are a very powerful tools to provide UI effects in addition to as well as without changes in the bitmap data and as such is a highly meaningful functionality to retain. The rework as you are currently envisioning it entails approx. 16 floats. If the alternative is alternative bitmaps, then that entails much more memory overhead even for the smallest widgets than the 64 bytes 16 floats would occupy (assuming a 32-bit platform).

That is true, in case this feature is used at all. If almost no one uses it then it is just a loss of computational speed and memory capacity.

Lastly, the ColourRect:s are part of the established API and set of features since the earliest versions of CEGUI and that is a third reason to retain them. I am not saying that all things ancestral must be retained out of reverence, but I am saying that what is a core-level albeit seldom used feature should definitely be retained.

If that is so then I agree. Long-lasting features should not be removed. That is, unless they are not used much. Which is what I tried to find out, but due to a small amount of participants in the survey I got no statistically relevant data.

The preferred solution would of course be to allow the user to in some what select which model to use: a simpler uniform colour with less overhead or a more advanced four-corner gradient with a cost associated. Again along the C++ ideal: as far as possible allow the user the choice and avoid charging for what is not used. I have forgotten the underlying structures so I don't know if this is achievable, but I thought I should mention this as something to consider.

Theoretically doing this is of course nice and possible. In practice it makes no sense: for example if this selection between the two methods is done on a per-widget basis then this would require shader switches between eachwidget of different type. This is way too costy and would defeat the entire purpose of reworking this. Additionally the XML and other parts of the code could not be simplified in such a case, as it would be if we removed this. So in that case, sticking with the ColourRects would be the faster, easier to maintain and better way overall. If the selection for this is done on a per-Renderer (or whatever) basis, then this just seems heavily unintuitive, especially in regards to what will be inside the XML as opposed to how it works in reality. Thus, I am heavily against providing both options.
Of course even if keeping the ColourRects, there is no reason not to rework them in the way I proposed before. It seems like a good solution to me after all and I am kinda in favour of that approach now. I plan to make a proof-of-concept in early-mid 2015 when I m done with my university semester.