what did you find the most efficient way of rendering the GUI objects?

The one that takes less work to implement. I've had quite some stir with GUI systems and I can tell for sure performance has never been a problem for me. Never. They just are not performance paths.
But, as a design rule, I'd try to minimize memory consumption rather than runtime performance.

A GUI rendering can be slow, because text rendering can be slow if there's a lot of text. So you can look into text rendering optimization.

I know you didn't ask for comments on the reinventing thing, but it's pretty strange that you are really reinventing the look of the standard win32 GUI.
If you want to release stuff with this GUI, it will kick your ass. And it will kick the users' ass. A GUI that just looks like the well known Windows GUI but doesn't work like it is a major user-anti-experience.

The one that takes less work to implement. I've had quite some stir with GUI systems and I can tell for sure performance has never been a problem for me. Never. They just are not performance paths.
But, as a design rule, I'd try to minimize memory consumption rather than runtime performance.

I'm guessing that you've never worked with Scaleform.

that you've never worked with Scaleform.

Of course not. I'm referring to the shitty systems I use here.

I've written this, but am not really sure it answers any questions, but perhaps you will find something useful here ;)

I would say that what you do would largely depend on your end goals (and those may change as time progresses). By this I mean if it's only ever going to be for use in your own projects, or if you intend a more general purpose library for use by the masses.

I guess some of what I put here is more aimed at a public lib and so it may not apply if what you're doing is only ever going to be for use in your own stuff.

It has to be said that to be completely general purpose and suitable for all possible scenarios is exceptionally difficult, if not impossible, to pull off. GUIs used for games and such may usually make assumptions and impose limitations that perhaps you can not if your GUI is to be used for non-game things. Editors and such can fall into either category, and which category any given tool falls into depends on many things IMO.

I suggest to create a brief “mission statement” that describes specific roles for your GUI and stick to that at all costs. Decide early on some limitations and stick to them rigidly. While “rigidity” sounds like bad advice, in the long run it will save you time, effort and keep your project lean, mean and on target at all times. Trying to be all things to all people is a slippery slope, and ultimately will split users into two camps – those that love the fact that you're willing to implement their feature request or modification, and those that think your lib sucks because it is complex or bloated – you cannot please all of the people, all of the time ;)

Current CEGUI performs rendering at various levels. The base level caches geometry for a window's rendering which remains unmodified and thus is reused until something changes on that window. By geometry, I do not mean four corners, 2 triangles or whatever, but geometry for all imagery drawn, so if the window has tiled a background and text, the geometry for drawing all those quads is stored.

In addition to this, we also support rendering the base level cached geometry back to a texture along with rendering for all attached child elements. This is generally used either for special effects or for optimisation purposes (if you have a page of text, rendering it to a texture first can be a massive performance boost – because drawing the two triangles needed to display the 'cache' texture is likely faster than drawing 20,000 triangles or more needed for a page of text). CEGUI makes this cache texture optional, and under the users control, since scenarios exist where always rendering to texture first will be slower – if we exclude special effects where it might always be needed, if some UI element is changing every frame, using a middle-man texture will slow things down instead of speeding them up.

We give access to the user to various parts of this pipeline so they can do their own thing, such as rendering 3D models. Having said that, it is also possible if the user renders the 3D model to texture, and then uses that texture to put the rendered model into a window. For our purposes that can be beneficial since it allows the user to cleanly update that model without having to hook into the CEGUI rendering process directly.

TL;DR: Keep it as simple as possible. Avoid mission creep. Don't let other people pull you off of your original vision. There is no one right answer and only you can decide what is best for your project!

CE