CEGUI (Crazy Eddie's GUI) Forums

@niello , I made a prototype for you and tested it. It generally works but has one big caveat I will get at later in this post. Please test it using this branch & commit:

https://bitbucket.org/cegui/cegui/commi ... 0be22a9563

You will need to call GUIContext::draw(...) and fill in the right DrawMode you want as parameter. For each window you will have to set a "DrawMode" property which is of type integer.

setProperty<int>( static_cast<int>(DrawMode::DM_OPAQUE) )

should work for example.

Now let's get to the big caveat.
What's not working:
Every window that has a AutoRenderingSurface set it true (framewindow default in 0.8.X) will render all its contents regardless. This will always show up. Maybe I overlooked something but the fix for this seemed not so easy to me. This is more or less a cache after all.


EDIT:
I think the above should be solvable by adapting this function to also take the DrawMode param and do the same as for the GuiContext functions:


What will never automagically work for AutoRenderingSurfaces though is a detection if a DrawMode of a Window has changed. If desiring to do this in run-time then the affected parents will need to be invalidated so that they are updated in the next frame. I think adding a listener or anything on that would be overkill.

@Ident: The type of the property being "int" is temporary, right?

YaronCT wrote:@Ident: The type of the property being "int" is temporary, right?

No. What's wrong with that?

There is two ways to go on about it in v0 and default:
#1 keep it as-is
#2 add a new property of type enum : short, that will be part of every window and signify the draw mode.

The latter has the advantage that we can create functions for this and make usage therefore easier and clean up the whole thing better. Also it will be stored as short internally then. Disadvantage is that every window will be bigger in size by sizeof(short). Not a tremendous amount obviously but for something that most people won't use, it may matter?

the disadvantage of #1 is that properties like this will be stored as string and then converted to int each time. Clearly a String("1") takes more space than a short. So if this feature is actually used a lot then it will end up taking more space than with approach #2.

Y not make a spcialized property helper for that enum, like u have e.g. for "AspectMode", and since branch "v0" store it as simply the enum (again, like "AspectMode")?

I wouldn't bother myself with space issues - I think we're past the days that the not very young of us remember when we had to deal with a 1MB or 64KB RAM. Really, it's hard for me to think of a scenario where the space of an "enum" would matter here, and I wouldn't mess with its size. Usually speed is more important so I wouldn't b surprised if compilers represent it as the fastest integer type or, if it's a smaller type, align it to multiples of the fastest type when it arranges the fields in the class.

YaronCT wrote:Y not make a spcialized property helper for that enum, like u have e.g. for "AspectMode", and since branch "v0" store it as simply the enum (again, like "AspectMode")?

Yea, that's specifically and exactly how it should be done. I guess you meant this should be done for v0-8 already and I guess you are right

I guess if we make it like with AspectMode we will have to do it as String not int.

There you guys go: https://bitbucket.org/cegui/cegui/commi ... 6a1ade8bf2

Any comments Yaron?

Final fix: https://bitbucket.org/cegui/cegui/commi ... 6a1ade8bf2

Using "UserString" instead of a property now. I think a property is not feasible in v0-8 or would be really annoying to shoehorn in.

Usage:

or if you like living on the edge:


I tested it and it works, now also for ARS

@Ident: Even in branch "v0-8" where u use a user string, u can still make it a property (of type DrawMode), where its setter and getter will set or get the user string. How the property is stored should b transparent to the cegui user, and shouldn't change between branch "v0-8" and branch "v0" (or later).

YaronCT wrote:@Ident: Even in branch "v0-8" where u use a user string, u can still make it a property (of type DrawMode), where its setter and getter will set or get the user string. How the property is stored should b transparent to the cegui user, and shouldn't change between branch "v0-8" and branch "v0" (or later).

Could, but wouldnt that force us to add an actual user String for EVERY window?

No. If the user string doesn't exist u can regard the property has having its default value.

Like I do now. True. I will try that approach

@Ident: And in the user string u can just store it as a string which contains an integer (the enum value) - the cegui user shouldn't use the user string directly anyway.

@Ident: I don't know if it matters much, but shouldn't this whole thing b implemented in "Element" rather than "Window"? The way I understand it is that elements knows about its area and to draw itself, but doesn't know about events.

YaronCT wrote:@Ident: I don't know if it matters much, but shouldn't this whole thing b implemented in "Element" rather than "Window"? The way I understand it is that elements knows about its area and to draw itself, but doesn't know about events.

Afaik an Element doesnt know anything about actual drawing. Window::render() is not derived from Element.