drawing economics
Blitz3D Forums/Blitz3D Beginners Area/drawing economics
| ||
| Hi yall I'm writing a gui a.t.m. and I'm wondering weather it would be better (more economical) to draw changing buttons when they are detected by the handler, or to stick them in a list and draw them in one go, when you are certain nothing changes anymore. The first method is simple, but has the disadvantage that; if several buttons interact (with each other and mouse-events)you run the risc of drawing the same button several times.(some of my buttons are beasts..) The second method takes a bit more planning, but offers more control. I just don't know weather it would cause the GPU to "stall", waiting for each draw to finish. In the latter case it would be better to draw that list before the handler, so the program could flow while the drawing takes place; and not wait on each other. ----sooo much considerations---- HA Hope anyone can shine some light in this. It's not THAT much of a problem now, but who knows what a gui will be used for in the future? |
| ||
| I don't think I fully understood your post., but if you're drawaing to the back buffer and flipping, you'll need to draw all the buttons and what-have-you each frame anyway, right? So it would be more efficient, I think, to determine the buttons' states and draw the reqired 'version'each frame. |
| ||
| well,not each frame per-say, but at least each cycle, yes. So drawing them as soon as possible seems logical. But I assume it will depend on how much time if takes for the GPU to draw a square, compared to the time it takes the CPU, to calculate what needs to be drawn, and in what order. hmm... How many line of code would take as much time as the GPU would need to draw "let's say" , a 16x16 16bit-image? |
| ||
| It's not going to be an issue..drawing 2d boxes, sorting them is not going to have a performance hit unless you are drawing thousands of gui elements each frame - even on a Pentium 2. |
| ||
| ehm.. one of my buttons consists of up to 100 "sub-Buttons" ;) when I scroll its content, the frame-rate drops from 80 to 40. Still trying to figure how to avoid drawing the whole thing instead of just the portion that changes, but this "question" is more about weather "in general" its better to draw all things in a row, or draw them as they come in view while checking the changes, with the risk of drawing them twice. |
| ||
| Take off vsync, via flip false. That will give you a more accurate frame rate and just use code to control the fps. What to do is this: (I believe it's called triple buffering) Draw your whole button, including sub buttons, onto a master image, big enough to hold all the sub buttons. Draw this image EVERY frame, however, only update that image, if there is a change, in which case, update the entire image again. That way, the computer is only drawing one image most frames. It's a bit like the idea behind 2d tilemaps. You don't draw every tile on the screen each frame, you draw these tiles onto a master image, the size of the screen, and scroll the master image left,right,up and down, and only update the image when new tiles are introduced. |
| ||
| Ross... that is brilliant! And exactly how I do it! hehe. I only redraw all the parts when the scrollbar is activated or when the 'user' sets its position 'by hand'. An extra advantage of 'triple buffering' is, that drawing to an image, and than that image to the screen, that image always will be 'compleet'. while drawing to the backbuffer directly can result in showing an image that is still being 're'drawn. Problem I face is, that the 'cells' of this 'scrolling button' have no fixed dimensions. Else I could 'predraw' them and use something like 'quadruple' buffering, instead of drawing background,picture and text of each 'cell' every time I draw the whole thing. Perhaps I could consider leaving it like this, since such 'gadgets' are more likely to be used for something like a database, and not something that needs realtime-drawing. .... it just bugs me ;) |
| ||
| Hehe, the hunt for efficiency. Things like that bug me too, and i never get anything done because i'm too busy refining parts of my code :o( Don't fall into that trap ;o) |
| ||
| too late! oink! |
| ||
| I also believe that for some time now, as the focus is on 3D graphics, GPUs are comparitively getting slower at 2D than 3D, meaning it may even be possible that a 3D sprite-based UI system may be more efficient than a 2D image-based one. Regardless, you're talking thousandTHs of millisecs here, so it's really not an issue. |
| ||
| Indeed I also thought in thousandths of millisecs, But I did just some testing: drawing a 32x32 image a 1000 times, takes roughly 50 fps. witch is 20 millisecs per 1000 drawings, so 1 draw takes 1/50th of a millisec. not a thousandth? Isn't that rather slow, or is it me? Drawing 4 lines to make a square of the same proportions takes 6 times longer than drawing an image... so that's kind of a nono. If these numbers add, I think I know where to find some bottlenecks in my progs. |
| ||
| drawing a 32x32 image a 1000 times, takes roughly 50 fps. witch is 20 millisecs per 1000 drawings, so 1 draw takes 1/50th of a millisec. not a thousandth? That does dsound INCREDIBLY slow.. are you talking about the time taken to draw the images and flip the buffer? Remember, that other factors will contributre to any methof of timing too, such as other processor concerns and other graphical concerns too. For best results, try closing all unnecessary processes and comment out any delays. Multiply the 1000 drawings so you're drawing something like 1000000. The greater this number, the easier you can determine the average speed per each. Keep your code extremely quick for the drawing. Use constant values all defined before any loops for maximum efficiency. I'm sure there's methods of deciding whether the background colour is worth writibng over if the pixcel is the same or closer enough in colour, but at some point, it'll either get silly or just not worth the hassle :D |
| ||
Are you sure your usingFlip False ? Remember also, you should let blitz set up, and put a delay right before your loop to measure your fps. |
| ||
| well: this is what I use; I get 14 for the time needed to draw 1000 images whith an fps of 68. Am I stupid or my PC?! /edit my X86 puts out:30 and 31 /end edit |
| ||
| You are drawing 1,000,000 images. NOT 1,000. |
| ||
| I divide timer by 1000, so it represents 1 repetition. I am curious though what others get for outcome. Or what the time SHOULD be drawing 1000 32x32 images? |
| ||
| Change from flip, to flip false and see what fps you get. |
| ||
| It's really dependant on your system specs of course. I ran a quick test and got a similar result (77 fps mean over 13 seconds for 1000 images sized 32x32 ) based on the equivalent of pretty good games playing hardware around 2-3 years ago. |
| ||
| Meh, graphics hardware for 2d is the same it was about 7 or 8 years ago. 1,000,000 images per second is a hell of alot though... |
| ||
| I can see why flip false would do nothing :o) I get 146 fps. |
| ||
| 1.000.000 seems much, but it means; if you want to fill a 800x600 screen,(20*25=500) with a framerate of 50, you can only redraw the screen twice per frame... |
| ||
| You should only be redrawing the screen once per frame :o) |
| ||
| hehe. pffft... |
   |