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
Ident
CEGUI Team
Posts: 1644
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Discussion on future removal or rework of CEGUI::ColourRect

Postby Ident » Thu Sep 11, 2014 13:57

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

KishukuOni
Not too shy to talk
Not too shy to talk
Posts: 25
Joined: Wed Nov 25, 2009 17:41

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

Postby KishukuOni » Thu Sep 11, 2014 19:06

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.

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

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

Postby Ident » Thu Sep 11, 2014 19:17

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

timotei
Not too shy to talk
Not too shy to talk
Posts: 25
Joined: Mon Apr 29, 2013 14:17

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

Postby timotei » Thu Sep 11, 2014 19:33

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

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

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

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

Postby Ident » Thu Sep 11, 2014 19:34

timotei wrote:I hate ColourRect and to me it looks like we can get rid of it :D 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: "I don't like GUIs"

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

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

Postby CrazyEddie » Sat Sep 13, 2014 21:57

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

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

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

Postby Ident » Sat Sep 13, 2014 22:46

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

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

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

Postby CrazyEddie » Sun Sep 14, 2014 16:04

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 :)

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

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

Postby Ident » Sun Sep 14, 2014 16:39

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

czuger
Just popping in
Just popping in
Posts: 17
Joined: Thu Aug 20, 2009 21:02

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

Postby czuger » Tue Sep 16, 2014 04:52

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

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

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

Postby Ident » Tue Sep 16, 2014 05:21

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

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

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

Postby Kulik » Tue Sep 16, 2014 11:18

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
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 » Fri Sep 19, 2014 10:23

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,

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

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

Postby Ident » Fri Sep 19, 2014 11:09

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

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

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

Postby Ident » Fri Sep 19, 2014 13:45

@ 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
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