Android – prevent “flicker” when calling drawable. Draw()

I have a small experimental application (basically a very simplified version of lunarlander demo in Android SDK) and only one surfaceview. I have a drawable "Wizard". I regularly draw canvas objects to surfaceview in different positions without trying to erase the previous image. Thus:

private class MyThread extends Thread {
    SurfaceHolder holder;  // Initialised in ctor (acquired via getHolder())
    Drawable      sprite;  // Initialised in ctor
    Rect          bounds;  // Initialised in ctor

    ...

    @Override
    public void run() {
        while (true) {
            Canvas c = holder.lockCanvas();
            synchronized (bounds) {
                sprite.setBounds(bounds);
            }
            sprite.draw(c);
            holder.unlockCanvasAndPost(c);
        }
    }

    /**
     * Periodically called from activity thread
     */
    public void updatePos(int dx, int dy) {
        synchronized (bounds) {
            bounds.offset(dx, dy);
        }
    }
}

Running in the simulator, what I saw was that after some updates, several old "copies" of the image began to flash, that is, appear and disappear. I initially assumed that maybe I misunderstood the semantics of canvas, and it maintained the "layer" in some way, and I was reversing it. However, I later found that if I tried to update at a rate of about 200 milliseconds, I can only get this effect. So my next best theory is that this may be an artifact that the simulator can't keep up with and tear the display. (I don't have a physical device to test yet.)

Which of these theories is correct?

Note: I don't really want to do this in practice (i.e. draw hundreds of overlapping copies of the same content). However, I want to know why

Environmental Science:

>Eclipse 3.6.1 (Helios) > JDK 6 > Android SDK tools R9 > app on Windows 7 is targeting Android 2.3.1

Tangential problem:

My run () method is essentially a compact version of how the lunarlander example works (removing all redundant logic). I don't quite understand why this won't saturate the CPU, because nothing seems to prevent it from running in full fur. Can anyone clarify this?

resolvent:

Well, I slaughtered lunar lander in a similar way to you. I can tell you that what you see is a simple artifact of double buffer mechanism for each surface

When you draw anything on the canvas attached to the surface, you will draw to the "back" buffer (invisible buffer). When you unlock canvasandpost(), you are exchanging buffers... When your "back" buffer becomes "front", you suddenly become visible, and vice versa. So your next frame drawing is completed in the old "front" buffer

The key is that you always draw separate buffers on alternate frames. I think there is an implicit assumption in the graphics architecture that you always write each pixel

After understanding this, I think the real problem is why it doesn't flash the hardware? After years of research on graphics drivers, I can guess the reason, but I hesitate. I hope the above content is enough to satisfy your curiosity about rendering technology