window grabbing and resizing? + rendering questions.

Is it possible to implement something like the window grabbing and resizing that most linux desktops use? It's really a very nice fast way of doing it, heres how it works for those not familiar.

Hold alt, and left click / drag the window from anywhere in the window (you can grab the window from anywhere, including on top of a button and the button wont trigger).

Hold alt, right click / drag the window from any of the 4 quadrents of the window to resize in that direction.

This is in addition to the common method of going to the title bar and dragging that, or to the bottom edge of the window to resize. Because you dont have to find little spots on the window to manipulate them its *much* faster and nicer to move windows around. I would like to have this for my game.

I started on a gui system for my game already in fact, and it already supports this (well actually its the only method it supports currently). <rant>However I have come to the realization that overlays are too slow, and very cumbersome in many ways. Frankly I really hope they are expanded to a point of being usable, or gotten rid of entirely so people wont waste their time using them after being drawn into using them assuming they provided the needed low level functionality one would normally need. Such an assumption is entirely reasonable considering that they are large classes that have a fairly extensive parenting system leading you to beleive that they can be used for more than a very simple overlay (after all if thats all you should be using it for, why all the extensive classes?)</rant>

So in short, my system has speed issues, heres a screenshot.

opening up 2 more instances of that calculator brought my fps all the way down to 180fps (from around 400-500), on my 8800gt.

So to someone whose gone through this himself, (apparently quickgui used overlays to start with?) how easy was it for you to redo your render system without using overlays, and how generally are you batching things? Did you notice a pretty substantial speed increase? I'm going to look at quickgui too to determine if it might be worth just dumping my code and using yours. Do you have any other advice to someone who is possibly facing some of the same challenges you encountered?

oh and heres a windows demo of my windows (using the alt grab resize/move stuff) so you can see how it feels. http://logicaldreams.net/HighSeas.zip
you will also need http://logicaldreams.net/cg.dll as I forgot to include it in the zip.

Thanks for any help.

Those do sound like great ideas. I'm not sure if I would implement them because other users might want to reserve the alt button for other purposes, but I would definately want to allow support of such a feature. I need to make sure enter/leave events are properly fired, but assuming this is correct, you should be able to create a handler for the WIDGET_EVENT_ON_MOUSE_MOVE event and program in the functionality. If the Left Mouse Button is down and Alt is down, move the move the window. I do think it would be difficult to implement the part regarding the ability to LMB down on even the close button and still be able to carry out this functionality, unless I allowed the Window class to be able to "preview" events. This is actually a cool idea..

Regarding the switch from overlays, we share some common complaints. It took some time to develop a rendering system not involving overlays. The latest release has a system that uses quad groups, that sort quads by z-order and texture, in that order. Every time you change textures for rendering you are creating another batch. The more quads you can render with 1 texture, the lower your batch count. But you can't simple batch all same textured quads together, they need to be drawn with zOrder in mind, so that quads overlap correctly. (quads are always drawn over previously drawn quads)

The performance increase was quite large when removing use of Overlays. I do not recommend using Overlays at all for GUI-like functionality.

If you are going to continue with your library, I recommend taking the RBGUI concept of rendering. Each window becomes a texture, which is updated whenever an element on the window needs to be redrawn. (instead of drawing to the viewport, draw to the texture) Using this method you can use the Ogre::RenderSystem::setScissorTest function and have it do clipping for you. Life becomes easy, you don't have to worry about quads and sorting them by texture and zOrder. All widgets draw themself to their window's texture, and the render system makes sure clipping occurs. Here is some pseudo code to demonstrate how easy clipping and drawing work together:

- save current clipping region
- set clipping region
- draw myself
- restore clipping region

The latest release I've put out is nothing like my current code base. I would encourage use of it, but its not released, and I still have a ways to go. As it is its useable, but it doesn't look good aesthetically, since the Skinning system hasn't been implemented, and I haven't redone borders. (I just have a folder with a bunch of textures, and hardcode the use of these textures, ie qgui.button.png, qgui.button.down.png, etc.)

If you want to see what I've done send me a PM. Either way you go it will probably save you hours and hours of time if you look at what I've done so far.

the way I did the resizing without things triggering was to have a variable in all my elements that would indicate if the window was being manipulated, if it was the window would not check for events.