Moving a runtime image across the window efficiently

[dodge55]

I'm not sure how to do this efficiently and without jitter, so I'll ask.

I created a runtime image (using rectangles, lines, ellipses). Using that function that draws the image, I tried to repaint the image with a WM_PAINT message and moving it 1 pixel to the right across the window continuously. There is a lot of jitter and after some time, it doesn't draw it correctly and as a side effect, my focus around my button tab at the top is off and it doesn't draw the focus correctly when I change tabs (window buttons) until I restart the window again. So, I know this isn't the right way to do it.

It might be that there are too many messages queued up and some are being dropped. Not sure. Also, not sure if there is a way to capture the image and save it to memory as a bitmap and display it across the window as a bitmap instead of drawing it each time. Also, not sure why the button focus is being affected by this.

Anybody done some animation where they can lead me to what they think the best method is for smoothness?

Thanks.

[jonnin]

cheating is the name of the game in graphics.
if you had... an image that was 1 pixel wider than the real image, and the first column were the background color, you can just draw it over and over, without erasing the previous image. This won't work if you have a background image or other drawn stuff (you have to get the column each time to do it this way). But if you can avoid erasing, it is smoother.
then its going to be loop of bitblt() calls, dumping the image over and over with maybe a tiny pause between or as fast as you can crank it out, depending on your needs.

a pixel is really small these days. you can probably move 5-10 per iteration and still be smooth enough. Play with that idea as well.

yes, you can get the image in memory and keep it in a reused object, and you should do that. You still have to draw it to move it, but you can keep it around and avoid reloading it. Some of this 'depends' ... if your program allows the user to resize the draw area, you have to deal with that, and get fresh device contexts, and so on. If its a static area, you can get them once and reuse them. If you need to resize the image due to resize of window, you can use stretchblt() instead of bitblt.

if the +1 column overdraw idea does not work for whatever reason (its a simple solution for a simple program) then you will need to double buffer to get it smoother. You may have to double up either way, but you can play with that too, to see if its required.

[dodge55]

Thanks for that answer. My app is simple. The image is static and the user can't change anything. It just moves across the screen manly as an 'intro' with no background in the way (for now).