I posted this as a comment on the blog (wrong place, I know) and am going to try to implement your suggestion (have to make sense of it first). 

I'll start this thread so that I have a place to discuss this, and because I'd like to suggest that you consider adding such support out-of-the-box. Again, I know I can rewrite it, but this seems like a core feature to me, not something I would have to figure out myself.

If you want your game to look like Microsoft Windows then you're in luck - the existing implementation supports that well. But creating something more like what you see in fantasy RPG games - an image-heavy GUI with backgrounds and ornamented corners, etc. - that's going to take significant work right from the start. It would be a huge bonus to have support for that by default.

I'm hoping to get to a point where I can quickly construct elements in more or less the following way:

Even if the above was in XML, the general approach would be much easier to grasp and ramp up with (at least for me). I don't know if it would be possible to do this without breaking what folks are already doing.

Just a thought. I'll keep poking at it. I really want this to be the system I choose - I like everything else I'm seeing, especially the regular blog posts and developer activity in the forums. Back to the documentation...

Thanks for your reply.

Over the weekend I spent some time writing something similar to your GUI library (but very scaled down), just to see what core concepts must be taken into account, what problems there are to solve, and so on.

I was able to implement a means of defining a control which has a 'border-and-corners' object (I called this a ControlFrame; I know that 'frame' means something else in your library). This allows you to designate areas of the base image which respectively represent the top, right, bottom, and left borders of a control, and also areas of that image which represent the TopLeft, TopRight, BottomLeft, and BottomRight corners. There's also a vector4 which represents the offset of the borders from the control bounds.

This works well and offers a lot of flexibility. You can decline to define a frame at all (null), define one with only a (say,) bottom border (for example a window title bar), etc. 

The problem I ran into was that there's no way to implement image tiling using SpriteBatch on a specific region of a spritesheet, and your system seems to be built around the spritesheet concept, presumeably for draw call efficiency. 

So any element - a button, a border, a background... - that you'd want tiling for would have to be done using one of two options: either extract render targets from those areas of the image at compile time, or simply use separate images for those components. The former is more compatible with your existing system but adds computational overhead at runtime. The latter also adds that overhead, but requires support for multiple images that comprise the GUI layer.

My feeling is that a design which assumes tiling will be used and also assumes multiple images is the most bang for the buck. I know the cost of using multiple images, but frankly there's no way to implement tiling without some extra cost, and the multiple images approach seems on par with that of render targeting - not to mention it's more flexible and intuitive (in my opinion).

Something to think about. I know you guys are swamped and are a small team. I may just end up writing my own GUI system. Looking forward to what you come up with in any case.

I believe the simplest and, in my opinion, most efficient method would be to do the tiling manually in the UIRenderer. For example: If an ornament image needs to be repeated n times at the top border of the control, then we can simple draw the ornament image from the theme texture n times.

This would only add a few draw instruction to the sprite batch.
The other approaches require renderstate changes (changing shaders, rendertargets, textures).

Adding tiling code to the UIRenderer should not be a big deal. I hope I get around to test this soon.

Very cool - can't wait to check it out. If by putting in extra weekend hours you're trying to guilt trip me into buying a license, it's working... :)