Moving things around the screen w/GDI

[NoCforMe]

Another project with problems.

I'm trying to learn how to move things around the screen with the mouse, using GDI.
Previously I was moving child controls around, for my DialogGen on-screen dialog editing program, so I pretty much know how to do that (although there are still problems with that scheme).

This time I'm moving other things around. Mainly bitmaps at this point.
I'm able to move them pretty well, but there are problems. Mainly flicker. Actually pretty horrible flicker.

(Use the attached program and move the NPN transistor around and see what happens.)

For the time being I'd like to keep this on a conceptual level and proceed without posting any code. (I'll be happy to do that later.) This isn't so much a problem with coding as it is with design, and with understanding how the OS works with graphics and what its limitations are.

What I'm doing is this:

• Creating a client window (using CreateWindowEx())
• Creating a memory DC from that window to use for drawing into which I'm calling AltDC:
• Using CreateCompatibleDC() to get a memory DC
• Using CreateCompatibleBitmap() to get a bitmap the size of the client window's display DC
• Selecting that bitmap into AltDC so the memory DC is the same size as the display DC

OK, now that I have a memory DC, I'm doing this:

• When the program starts, I draw all my "objects" on the display DC, through WM_PAINT. This includes the blue rectangle, the big text and the bitmap. (So far AltDC is just blank, set to the background color.)
• When the user clicks on the bitmap (determined through hit-testing), I draw the selection box (dotted line) around the bitmap; the bitmap is now considered "selected".
• If the user holds down the left button and moves the mouse, here's where things get interesting:
• I go through the list of "objects" and I draw all of them except the bitmap to AltDC; this is my "clean slate" to use later
• I draw the selection box around the bitmap to the display DC
• I draw the bitmap to the display DC, at the current position
• As the user continues moving the mouse, things get really interesting:
• For each move, I first restore the image underneath the bitmap, copying just the bitmap's rectangle from AltDC (which has the "clean slate" before I drew the bitmap)
• I then draw the selection box and the bitmap at their new positions on the display DC

As you can see this works, but at a very high price. If you move the mouse at any speed above s-l-o-w, it flickers badly.

Any ideas here? I'm pretty sure I'm doing what I'm doing correctly, so far as coding goes. In other words, I don't think this is a matter of bugs. More a case of poor use of resources.

Am I doing too much moving of stuff between DCs? is that what's causing the flicker?
I was hoping that by only copying a small part of AltDC to the display for each mouse move that I'd be avoiding too much processing.

Should I be doing some kind of double buffering? (Not even sure how that works, to be honest.)

Any better way to do what I'm trying to do here?

[zedd]

For starters, you have a gdi leak...

Also, double buffering would indeed help.

You cannot view this attachment.

ALso that white rectangle with border appears sometimes when moving the transistor around.

[NoCforMe]

For starters, you have a gdi leak...

No doubt. Let's not worry about that for the moment. That's not the problem.

Also, double buffering would indeed help.

I'm going to read up on it next thing.
Well, a quick read showed ... basically the code I have now.

Question: Does using double buffering mean that I draw everything to a separate buffer (my AltDC) and then copy that entire thing over to the display DC? Because I'm not doing that exactly.

[zedd]

This is how I would do it... and so far works for me.
If you have the client area already from GetClientRect, you can use that here instead of ps.rcPaint...

Code Select Expand

        .elseif uMsg == WM_ERASEBKGND          ; adding this helps greatly with flicker issues
          mov eax, 1
          ret
        .elseif uMsg == WM_PAINT
          invoke BeginPaint, hWin, addr ps
          mov hDC, eax                          ; window client area DC
          invoke CreateCompatibleDC, hDC
          mov memDC, eax                        ; memory DC

          invoke CreateCompatibleBitmap, hDC, ps.rcPaint.right, ps.rcPaint.bottom
          mov hBmp, eax                        ; compatible bitmap handle
          invoke SelectObject, memDC, hBmp
          mov hBmp_old, eax

          ;; ###########################################################

          ;; in this example do all of your drawing here to memory DC (memDC) not to window DC (hDC)



          ;; ###########################################################
          ;; bitblt memory Dc to window DC
          invoke BitBlt, hDC, 0, 0, ps.rcPaint.right, ps.rcPaint.bottom, memDC, 0, 0, SRCCOPY
          invoke SelectObject, memDC, hBmp_old
          invoke DeleteObject, hBmp
          invoke DeleteDC, memDC

          invoke EndPaint, hWin, addr ps


[sinsi]

Question: Does using double buffering mean that I draw everything to a separate buffer (my AltDC) and then copy that entire thing over to the display DC?

Yes, everything.

I get artifacts when the bitmap is dragged past the top or left
You cannot view this attachment.

[NoCforMe]

Question: Does using double buffering mean that I draw everything to a separate buffer (my AltDC) and then copy that entire thing over to the display DC?

Yes, everything.

I get artifacts when the bitmap is dragged past the top or left

Yes, shoulda warned you 'bout that. There's no code to check for boundary conditions (yet). Makes a mess.

So maybe I should concentrate on "everything"?

[zedd]

I will also add that however you are selecting the transistor and moving it around, that part indeed is working nicely. Congrats. 
I had tried something similar years ago, but with piss poor results. 

I think I could do something similar now, if needed, though -with better results.   

[zedd]

So maybe I should concentrate on "everything"?

Work on getting the double buffering working first. Once done, then you can do the boundary checks, and handle the resource issues (source of gdi leaks), imo.

[NoCforMe]

Progress!

After fixing a basic mistake, you can see that moving that bitmap around is now very smooooove. All because of buffering.

(Just a side note: I'm not using the term "double-buffering" because I don't even know what that really means: what's "double" about it? I'm actually using 3 buffers here. See below.)

Here's the scheme I'm using:

You cannot view this attachment.

I create 3 additional DCs:

• A source DC
• A work DC
• And a li'l DC for the bitmap

The source DC holds a rendering of everything except the "object" being moved (hereafter referred to as the OBM). It's a baseline image used for restoring parts of the image overwritten when moving the OBM. It's only created once, when mouse movement first starts, so that saves the expense of redrawing everything for each mouse move.

The work DC is, as the name implies, a work area for drawing into.

Both the source and work DCs are sized to the display DC (by creating a bitmap from the display DC using CreateCompatibleBitmap() and selecting that into the DC).

When the OBM is moved (when we get a WM_MOUSEMOVE message), the first thing to do is to erase the OBM, including its selection outline, at the "old" position (where it currently is on the display). This is done by copying that part of the source DC to the work DC.

With the underlying image restored to the work DC, the selection outline and the bitmap itself are drawn into the work DC. This can all now be copied to the display DC. The trick here is to make the copy rectangle equal to the union of the "old" and "new" display rectangles, so that the old left-behind parts of the OBM are erased and the OBM shown in the "new" position.

It all works pretty well. However, as you can see if you run the demo, there are still some leftover parts that leave garbage on the display. (The interesting thing is that if you play around with this long enough, it stops leaving stuff behind. I don't understand why.) I'm guessing this is because of an "off by one" error or some such.

Anyhow, play with it. It's so much smoother than before: no flickering that I can see.

BTW, one thing I learned is that Windoze definitely doesn't like it when you select the same bitmap into two DCs. So when I used CreateCompatibleBitmap() from the display DC, I had to do it twice to give me two separate bitmaps to select into the source & work DCs, to make them the same size as the display.

[sinsi]

saves the expense of redrawing everything for each mouse move.

Have you tried? Sometimes fiddling around is slower.

If it's only one thing moving at a time, you could make a bitmap when starting the drag and use it as a background brush.
Then you just need to paint the background to the memory DC with the brush, paint the dragged object and blit to the window DC.

The width of the artifacts depends on the mouse speed, maybe mouse acceleration is skewing measurements?

[zedd]

I am not sure if my finger slipped off the left mouse button while moving the transistor (its possible), but at one point I had two transistors on the screen at the same time. I screen captured it.


I could not however recreate that error.

Other artfacts:


No source? 
Let the source be with you... and with us, too. 

[NoCforMe]

Yeah, yeah, the artifacts.
It's interesting that they come from the corners of the bitmap. That oughta tell me something.

@sinsi: that idea of using a background brush is intriguing, but I'm not sure I understand it.
Could you explain it a little bit more? Are you suggesting using the image of everything except the OBM (object being moved) as a brush?

[sinsi]

Are you suggesting using the image of everything except the OBM (object being moved) as a brush?

Yep. Since everything else is static, you could draw it once (to a bitmap or brush) then use it as the background.
 - mouse down -> create bmp then optionally brush (the bitmap can be deleted if you use a brush)
 - mouse move -> double-buffer draw - fill memDC background with it, draw OBM to memDC then BitBlt memDC to winDC
 - mouse up   -> delete bitmap/brush
You won't have any gaps, so no artifacts.

I've never actually used a brush from a bitmap but it seems easy enough (provided you have a bitmap) with CreatePatternBrush.
It looks like a brush is easier to paint with, but a bitmap should still be OK using BitBlt.

[NoCforMe]

Sinsi, your explanations about using background brushes and such will have to wait for another day.

My current motto: Simplify, simplify, simplify.

Check out current iteration. Totally smoooove moving, and no garbage left behind on the screen.

I totally eliminated all the "erasing the leftover bits from the last drawing" stuff.
Now all I'm doing is this:

• First time through I draw everything except the OBM to SourceDC.
• For each move I copy the entire SourceDC to WorkDC.
• I draw the dotted outline box and the OBM bitmap to WorkDC at the current location.
• I copy the whole WorkDC to the display DC.

Even with the slightly increased overhead of copying the whole DC every time, it's still smooth.

Sometimes the simpler solution is the best.

[sinsi]

OK, that's basically what I said