Discussion on future removal or rework of CEGUI::ColourRect

Official announcements from the CEGUI project.

Moderator: CEGUI Team

Do you use the ColourRect feature of CEGUI?

Poll ended at Sat Nov 29, 2014 18:44

I never used ColourRect and do not plan to use it in the near future
7
64%
I use ColourRect regularly. It is an important feature to me and I wouldn't want to miss it in future CEGUI versions
2
18%
Other (make a post!)
2
18%
 
Total votes: 11

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: Discussion on future removal or rework of CEGUI::ColourR

Postby Kulik » Fri Sep 19, 2014 14:39

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.

User avatar
Ident
CEGUI Team
Posts: 1836
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Re: Discussion on future removal or rework of CEGUI::ColourR

Postby Ident » Fri Sep 26, 2014 18:24

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.
CrazyEddie: "I don't like GUIs"

Bertram
Quite a regular
Quite a regular
Posts: 73
Joined: Wed Oct 02, 2013 14:46

Re: Discussion on future removal or rework of CEGUI::ColourR

Postby Bertram » Wed Nov 26, 2014 13:54

Hi there,

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

best regards,

User avatar
Ident
CEGUI Team
Posts: 1836
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Re: Discussion on future removal or rework of CEGUI::ColourR

Postby Ident » Wed Nov 26, 2014 15:35

Bertram wrote: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.
CrazyEddie: "I don't like GUIs"

User avatar
Mikademus
CEGUI MVP
CEGUI MVP
Posts: 130
Joined: Wed Mar 18, 2009 19:14

Re: Discussion on future removal or rework of CEGUI::ColourR

Postby Mikademus » Sun Nov 30, 2014 13:32

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! :hammer: <-- I've missed this emoticon


Edit, having read the thread now:

Ident wrote: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.

User avatar
Ident
CEGUI Team
Posts: 1836
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Re: Discussion on future removal or rework of CEGUI::ColourR

Postby Ident » Sun Nov 30, 2014 20:07

Mikademus wrote: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.

Mikademus wrote: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.


Mikademus wrote: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.

Mikademus wrote: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.
CrazyEddie: "I don't like GUIs"


Return to “Official Announcements, Works in Progress, and Future Directions”

Who is online

Users browsing this forum: No registered users and 1 guest