Yes he could, but that's not what he wants to do. And it would look terrible and be awfuly sloooooow if there were a lot of graphics on the screen such as you might see in games.
But thats what happens in real games -- the whole screen in cleared and the updated graphics are redrawn.
As a matter of fact, this is the very way display devices work. The whole screen is erased and redrawn and the frequency of that depends on what we know as the refresh rate of the monitor. (normally measured in Hertz)
And strange enough this is the very way API's like DirectX and OpenGL work, erasing the screen and redrawing the next frame.
I don't know much about game programming, but I would think they actually use two (or more) screens -- the screen(s) being drawn is in the background then just flip screens when its time to display it. That way we don't see the flicker.
Yes rightly said -- its known as [search]Double buffering[/search] in which the next frame to be drawn is written to the RAM (in case of software implementation) or the the VRAM (hardware implementation) and is then displayed on the screen in the next frame.
Just FYI, there is also an advanced way to achieve it known as [search]Triple Buffering[/search].
Back to the OP's question -- I doubt if he is using double or tripple buffering, just drawing on the screen as needed, which is why I said it would be too slow to erase the whole screen and redraw it.
Hmm, I've done a bit of game programming, and double/triple buffering does NOT draw it any faster, in fact it's actually slower, because you have to redraw the entire frame (or else you end up with a picture that's already 2 frame old). Instead, it simply prevents the user from seeing the frame being drawn until it's finished (thus preventing a flicker).
As for drawing, I would say drawing a black box to cover up the previous position of the box is the best solution; since there's no double buffer, it's best to do as minimal drawing as possible to minimize flickering (which also speeds up the process).