Quote:As pointed out earlier the large drop in frame rate should be of no concern. It is natural that doing something will be much slower than doing nothing. Look at it this way, your eye only starts noticing problems below about 25 fps and cannot tell any change above about 55-60 fps, so don't worry about it. Also, the change you are seeing (from 900 to 90) is drastic but you have to understand that this trend is not linear, you will have to do quite a lot more to get it down much more than that.

Quote:This may not be helpful, but why are you so bothered with the FPS of your GUI? It's not a part of the system that should need optimising. When nothing is changing 0fps will suffice. When dragging windows think how slow MSWindows is at doing it smoothly - and that's what everyone will be used to so they won't care if your windows 'judder' at 10fps when moved/resized.
Personally I'd rather work on the game... I can understand the perfectionist approach to optimising everything to the max but that's not godd software engineering IMO.

I'm developing an RTS so a lot of the UI will be visible during the game, and I want it to take as little time as possible away from the rest of the frame. This is another reason I'm doing it like this, so when the user is doing stuff with the units and such it takes less time to render the UI.

I'm not worried about the drop in framerate, simply how long its taking to render large dirty areas. Yes, 100 fps isn't visible, but that means its taking 10 milliseconds out of a target 30 millisecond frame time, and on a relatively powerful machine at that. As long as the idle rendering time is less than 5% a 30 ms frame I don't care about it.

I can live with a little stutter while resizing stuff, I just thought it might be a quick thread to get some help with a faster FillRectangle, so why not?

Quote:One other point, fps is a pretty terrible way of gauging performance in cases like this. You need to be profiling and checking the execution time of specific functions or function groups. If the window scrolling is slowing the fps down to 90 then this won't be a problem as it is likely that the user cannot scroll on more than one window at once.

I understand this, I have no excuse, just too lazy to get started with a profiler (very recently switched to VC 2003 from VC 6). I am 100% sure the slowest function is FillRectangle however, if I double up filling the window background call (ie do it twice), it nearly doubles the rendering time.

Quote:Hope this helps. Take it easy, and good luck with the program, it's looking real good.

Thanks!

Quote:Why not (as an optional performance enhancement) put the window data into a texture, whack that onto the window vertices and just scale it out?

Interesting idea. I suppose I could also render the new size to a separate texture and interpolate switching over a few frames so it doesn't snap between resolutions.

I give up on this for now, after the GUI is in use in game and find it to be a problem to redraw large windows I'll come back to it.

Thanks for all the help.

Hi Kibble,

perhaps this link is useful if you are interested in a fast memcpy-routine:

http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_2272_2274,00.html

it's AMD's optimized memcpy for athlons and durons