xgui - performance test

Community Forums/Showcase/xgui - performance test

skn3(Posted 2004) [#1]
---- = Edit = -----
UPDATED: test
http://skn3.acsv.net/junk/xgui_test2.zip
---- = Edit = -----

Anyone interested please test the following file. It is a gui for a game I am creating, and I need to test it's performance on various systems. It uses gadget buffering/realtime renders seamlessly, and can be skinned extensively.

At the moment it uses an image to composite all buffered gadgets into one. So a double buffered method. However drawing these to screen (especialy when they are large) casues a big impact. This is something I want to see if it happens on peoples systems.

Unfortunatly I can't think of a better alternative for buffering whole gadget groups so it will have to do for now.

http://skn3.acsv.net/junk/xgui.zip



Big&(Posted 2004) [#2]
FPS:86


Rob(Posted 2004) [#3]
clever and fast! locked to refresh rate (85 etc)


Daz(Posted 2004) [#4]
I am using my work machine which isn't the fastest machine in the world (Intel 82845G/GL graphics card), but I was still getting 68 fps. I will test it on my home machine when I get home tonight.


morduun(Posted 2004) [#5]
60fps mainly, 55 when first selecting a window, but I could force it down to 35 if I resized the 'resize me' window wide enough to display the large button and clicked on the button furiously :) Probably not a good real-world test, but that's as slow as it got.

P3/1G, ge4ti/4400, 256MB, winXP


Grisu(Posted 2004) [#6]
Locked to my max FPS of 60.

AMD XP 2100
512 MB DDR
Ati Radeon 9600XT 256 MB


Dragon57(Posted 2004) [#7]
85 on the machine w/the Geforce card in my sig.


skn3(Posted 2004) [#8]
Cool thanks for testing. The results seem good, but annoyingly I found a bug which meant that buffereing was being overwridden, so it was always drawing all the time. DOH!

So the results probably don't show much X)

I'll probably post an updated test once I figure out how to fix this bug.


skn3(Posted 2004) [#9]
http://skn3.acsv.net/junk/xgui_test2.zip

Ok fixed it, had to rewrite a major chunk to be more organized X)

Currently in this test has maybe 3000 gadgets on screen (around 3000), so this should be a good jusge if my system can cope!


TartanTangerine (was Indiepath)(Posted 2004) [#10]
Maxes out at the monitor refresh rate, maybe use Flip False to get a true FPS.


N(Posted 2004) [#11]
60 FPS. My monitor refresh rate is 85hz so it's not capping there.

On average, it's pretty fast, the only real problem is that when you refresh a great deal of the image, it will go extremely slow for a bit.

I'm gonna take a wild guess (not really wild or a guess, but hey, it sounds better) and say that you can't use 3D? If you can, then what in god's name are you doing using 2D? (I could add more to that, but I feel that sums it up).

Anyhow, looks nice, although the aliasing on edges is a bit ugly on anything that isn't 45/90 degrees.


skn3(Posted 2004) [#12]
Im making this in b+ so no, can't use 3d. It would require I start faffing around with single surface systems also, and I'd rather not have to deal with the texture dimensions hardware limit. Besides, there is much more optimization that can be done to this. Currently if you toggle a button in a window, it will update that entire window. I guess I'll make it only update the rect (would mean doing a scan for al l rects under it, due to masked graphics) the changing gadget is overlapping.

Can I ask what fps it was running at when you were idle, away from any gadgets ?. If it was 60fps, what are your pc specs. Note that in the test it is drawing 5 500x300 images each frame. So that is probably the bottleneck.


morduun(Posted 2004) [#13]
This one's much slower. I can shove it down to under 25fps simply by resizing windows (there's a VERY noticeable pause -- at least 500ms) when I click the window resizing area), and under 20fps by making that one resizeable button extremely large and pushing it. If I fill the entire drawable area with those windows it bloody well crawls. Idle speed with a mouse hovering over a hotspot on a window is 30fps; if the mouse is in the 'desktop' area or a neutral window area like a titlebar it's 60.


AntonyWells(Posted 2004) [#14]
If you want to speed up window resizes, after a resize devide the window off into new/old space. (Old being already computed), then just update the gadgets in the 'new' space'

Result = downsize=instant, upsize=much smoother.

It would also be beneficial to view each window as a grid, rather than a whole. You can then v.easily make the window bigger, faster still by not having to reclaim a window size region in vid mem.

Just a suggestion, take it or leave it :)


skn3(Posted 2004) [#15]
Yeah once again I think the slow-downs are due to some bugs XD.

This code is pretty complex already with just windows and a few gadgets, 3500 lines o_O. For some unkown reason it is continuously refreshing after the initial refresh when you hover over certain gadgets.

When you resize a window, it will put its root group into realtime render mode. This will reuse gadgets that are buffered, and realtime draw gadgets that are able to resize (like titlebar, clientarea etc). Only when you stop resizing will it reallocate the memory used.

I think my next step now that I have it isolating the groups that are active, is to as you suggest, only update the parts of that group that change. Which wont be a pleasnt task.

Believe me, this test is faster than the first one, I tried the same number of windows/gadgets on the previous code and it crawled at 10fps on my rig. (current idle with flip false now is 800-1000fps). Anyway, back to coding.

Thanks for testing again :)


N(Posted 2004) [#16]
Can I ask what fps it was running at when you were idle, away from any gadgets ?. If it was 60fps, what are your pc specs.


That was the idle FPS.

PC:
P4 2ghz
GeForce 3 ti200
SoundBlaster Live! Value
512mb DDR RAM

Those're the only things I think would affect the actual FPS outside of the actual internals of drawing the GUI.

Anyhow, I expect the slowdown is not only due to the drawing of the rather large window images (buffers, blocks, etc.) but also some general areas handled by the code. In any case, I do like the work you've done on it.


Jim Teeuwen(Posted 2004) [#17]
Maxed out on my refresh rate (75fps)