Tim Robinson wrote: I saw your post on mouse pointers. Currently I erase the old one then draw the new one; and there's no transparency, so you can only have square pointers. I think what I should do is:
If the old pointer rectangle and the new one intersect:If they don't intersect then I don't think there will be any flicker problem.
- Create an in-memory bitmap big enough to span the two rectangles
- Copy from the screen into the bitmap
- Copy the saved "underneath the pointer" bitmap to the bitmap, to erase the pointer image
- Copy the bitmap to the "underneath the pointer" bitmap
- Draw the new pointer to the bitmap
- Draw the bitmap to the screen
BI lazy wrote:
I use the trick with the area spanned by two "displacement rectangles" to move window boxes around the screen with a small amount of flicker - this you just can't avoid.
for the mouse: to get it transparent, I use the same mechanism like for drawing font: where a pixel is set in a valid colour in the bitmap, there I draw a pixel. If naught is to draw, then the area remains unchanged.
I too erase the pointer before redrawing it - animation requires it, no help from that. either you redraw the area underneath from a double buffer or from some kind of "what's beneath" bitmap owned by the mouse pointer. But which ever method I use, I have to do a "wait-for-vertical-retrace()" call to avoid flickering whilst moving the pointer.
that's how I do a normal mouse-movement without dragging some window-box around:
1. wait for vertical retrace
2. restore what's beneath the mouse pointer - old location
3. paint the mousepointer to the new location and meanwhile save what's beneath.that's roughly my mouse painting thing. this way is described on some website I remember as www.brackeen.com.Code: Select all
buffer[bmp_offs]=vid_mem[offset+x]; if(bmp[bmp_offs]){ vid_mem[offset+x]=bmp[bmp_offs]; }
Tim Robinson wrote: I see what you're saying. I seem to have overlooked that. I wonder how I could integrate waiting for vertical refresh (into the kernel-mode driver) without using too much CPU time.
It would be useful to provide a generic rubber banding mechanism to apps, not just for dragging windows. The window manager could keep a list of them; when one was to be moved, it could wait for the vertical blank interval. It could also prevent them from being drawn over by other programs. Windows seems to do this for window rectangles, but not in a general case: if you drag a dockable toolbar in an MFC app, it locks the display until you release the mouse button.