Is it quicker to draw rectangles, or images for buttons?

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|717\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> Is it quicker to draw rectangles, or images for buttons?
Mon, 09 Nov 2009, 02:56
LostUser	I have built a button library which has different themes, such as rectangles, 3d button effect, and several rounded rectangle functions. All the themes are pretty basic. In my Draw_Buttons.button() function it does a big switch statement to find out what theme you want to draw when on mouse-over and what theme to draw on mouse-out. However, sometimes I feel the drawing is too slow (it may just be an illusion), and I'm not sure drawing rectangles every loop is all that efficient. One solution I am using is that I delete all buttons before and after using them to save on memory. Another issue is some of the rounded rectangle functions can be slow if you have a lot of them on the screen. I know that the fatBox() function is very slow and that the only one that works fast is a rounded rectangle function that Jayenkai posted. However, that being said I'm thinking -- wouldn't it be faster to render every button theme as an image, rather than buttons? I've tested an example where when it creates a button, it will create a temporary image on the fly which captures both the off/on state in the button type. Then, when I come to draw the buttons I have much less coding to do every loop. repeat cls // Pseudo-code for b.button = each button if (mousein(b\x, b\y, b\w, b\h)=true) then DrawImage b\gfx_btn, b\x, b\y, b\frame_on ; frame_on=0 else DrawImage b\gfx_btn, b\x, b\y, b\frame_off ; frame_off=1 end if next if keyhit(1) = true then done = true flip until (done = true) --v The benefits of the approach is that I guess there is much less coding in the actual loop where the drawing part happens. The only downside is that I would not be creating and deleting buttons on the fly (ie: deleting/making buttons before/after usage) because images would then have to be re-created everytime (thus making processing slower). So, the image buttons solution has the issue that the images would be a one-time event only. That being said, I'm still not sure if it is faster to draw rectangles or store all the rectangle themes in a temporary image with frames (for mouse-in and mouse-out). Any help on this issue would be most appreciated. Thanks.
Mon, 09 Nov 2009, 03:19
Jayenkai	It's usually quicker to draw images, because for whatever reason Blitz tends to suck at drawing rectangles, and it's even worse for Ovals! If I'm going to do a lot, I tend to build a buffer, draw the rect/button to the buffer, then draw that image. Type ButtonBuffer field Title$ field r,g,b field image End Type Function Button(x,y,Title$,r,g,b) UseImage=0 ; Check for Duplicate for BB.ButtonBuffer=each ButtonBuffer if bb\title$=title$ and bb\r=r and bb\g=g and bb\b=b then UseImage=bb\image next ; If no Duplicate, draw new button if UseImage=0 bb.ButtonBuffer=new ButtonBuffer bb\r=r:bb\g=g:bb\b=b bb\Title$=Title$ bb\image=createimage(width,height) ; Imagebuffer setbuffer imagebuffer(bb\image) color r,g,b rect 0,0,width,height,1 text x+(width/2),y+(height/2),Title$,1,1 ; Back to norm.. setbuffer backbuffer() UseImage=bb\image endif drawimage x,y,UseImage End Function --v Which will essentially build up an ever growing library of buttons that can be reused without constantly rebuilding them every single frame. You probably want to add a clear routine whenever you switch from one screen to the next, to free up whatever's not going to be needed, otherwise you'll end up using many millions of megs, just for all the buttons! for bb.ButtonBuffer=each ButtonBuffer freeimage bb\image delete bb.ButtonBuffer next --v -=-=- ''Load, Next List!''
Mon, 09 Nov 2009, 03:58
LostUser	Hi there. Thanks for your reply. Your answer is very clear and helpful. The way I seperate buttons for different screens is a "screen$" and in my Draw_Buttons.button() function I use the screen$ as a parameter, so it only shows the buttons from "screen$" With regards to the clear routine, I have a question. Let's say you have a screen with buttons on them, you use the clear routine and go to the next screen. The user presses Escape to return to the previous screen; however the clear routine has removed all the butttons. Does this mean I have to rebuild all the images/buttons again? I'd like to avoid rebuilding all the images over and over again. Am I right the button buffer gets rebuilt every time? Thanks.
Mon, 09 Nov 2009, 04:12
Jayenkai	Yeah, it'd rebuild every button after a clear. But even with 100 buttons to rebuild, it's not exactly going to take a minute to do. Let it do it once, during perhaps a black faded screen inbetween each different screen. It won't take too long to rebuild that many buttons. -=-=- ''Load, Next List!''
Mon, 09 Nov 2009, 04:14
LostUser	Okay, thank you for your help. I will try and adapt your idea to what I already have. Thanks again for your help.
Tue, 10 Nov 2009, 08:28
JL235	Zardon and I'm not sure drawing rectangles every loop is all that efficient. I just want to pick up on this point. Yes, redrawing a GUI on every frame is not the efficient way in which you do it. GUIs are usually event based and so draw on demand (on key press, mouse move or some other repaint action). Event based drawing is typically far more efficient for applications because whole minutes could pass between drawing. So the application can spend a large amount of it's time sleeping; just waiting for incoming events. If your building a GUI for a game, then this isn't an issue because I expect the game will need to redraw on each frame. If your building a GUI library to build applications with BB, then I'd recommend taking a look at existing GUIs (as research) to see how event based GUIs work. You could then build something similar in BB. Have you ever had an application where it's all painted incorrectly, but as you mouse over the buttons/menus they one by one repaint correctly? This is another trait of event based systems, only the bits that need to repaint do repaint. So if you click on a button then only that 1 button repaints, the rest of the application will not paint at all. You could try something similar where you paint your GUI to one massive image, and then changes to the GUI are reflected by redrawing to this big image. It'll mean drawing the entire GUI is one image draw (as opposed to hundreds of little ones).