Optimization Issues

[Labdabeta]

I quickly threw together a drawing program in SDL and I am having a couple of issues with lag. The program lags really hard when the size is larger than about 700x700 pixels, and I cannot find anything other than a couple of SDL_BlitSurface calls to the 'image' surface in the step function. How long does SDL_BlitSurface take? Also the step function returns the image that I want to blit to the screen, as such I call SDL_BlitSurface to blit its return value to the screen surface. How much time would I save by passing the screen surface to my step function so that it can blit directly to the screen. Finally, the program works by drawing small circles at the cursor position every time step is called while the left mouse button is down. Unfortunately if you move the mouse fast enough you can cause small dots to be drawn instead of a continuous line. From testing I found that it seems like MS paint seems to draw a line from point A to point B when that happens, how can I do this fast enough to make it worthwhile? If you need any sections of the code just tell me.

[Moschops]

There's really only one way to be sure; you have to measure. Either with some kind of code analysis tool that monitors how long functions take, or by sticking in logging and recording the time, or whatever other ways you can think of, but trying to guess what's taking up all the cycles is often a way to do a lot of extra work for not much improvement.

It's not impossible, of course, but so many times I optimised something that I was sure was the cause of a delay, and so many times it finally turned out to be something else. Now I always measure. It's really, really the only way to be sure.

[Labdabeta]

Could you name one such analysis tool? Also when it comes to the making of dots rather than lines I am well aware of the issue, its that the mouse can move more than 1 pixel in a single frame. I think the solution is to somehow interpolate a line from where it was in the previous frame to where it is in the last frame. I just don't know an efficient way of doing this. I was thinking of using a bresenham algorithm to plot the center points along the route and then plot a circle of the correct radius at each generated point. This would create the desired effect, but I fear it may be very slow since most mouse movements are 1-3 pixels and drawing 3 circles when 2 would suffice seems like a waste. I am wondering if there is some way to optimize that issue.

[Labdabeta]

Ok, I fixed the dot issue with an optimized version of the bresenham algorithm. I also resolved the lag by 'flattening' my surfaces earlier so that rather than blit a bunch of small surfaces on to the big one seperately, I combine them and blit them all at once. IE if A,B,C,D,E are surfaces that I want to put onto F then I would do:

A+B=AB
C+D=CD
AB+E=ABE
ABE+CD=F

which brings the number of combinations onto my large surfaces (the big two being the image and the screen) way down. Thanks for the help though.