The tics in the emulator are 1/10 seconds and they are 1/64 in the device. That's why wait makes it very slow in the emulator.
Note that you do not necessarily need to work in an offscreen bitmap. You can use the screen buffer for double buffering. Once you have drawn in the screen buffer what you wanted, then use
You save a lot of time that way.
Screen buffer is not flushed until you do it. Only when using window server, it would update the screen from the screen buffer automatically. Window server flush is not needed, unless you are using Window server drawing commands. To make it fast, you should not.
i'm not actually using double buffer, it's only a sample
i'm just drawing some bitmap onto screen, i.e. using the screen buffer for double buffering
i have changed timer generation interval to 1
is the first operator in RunL() method blitting works perfect, but slow (~20 fps)
if it is the las operator before After() it shows 64 fps, but flickering appears!!!
Updating the screen last sounds right to me. Having drawn it all, then do the screen update.
Do you count the actual frames per second? In my experiments, I thought it was updating slow, but actually it was extremely fast. Try with a longer wait and see if that's the case or not. You can judge it from the reduced flicker... This may not be a case, but I thought I'd mention it anyways.
64fps is about the maximum that one can do. If you are blitting full screen 30 fps may be the maximum you ca do without flicker. If you are blitting smaller areas, you can do about 60 fps without a flicker. But you'll have the tearing in the screen, because we don't have vsync.
And again, make sure you don't flush the window server, because it's not necessary...
From the Direct Screen Access classes you get only the Graphics context. If that does not serve you, you can get the screen buffer address with ScreenInfo and handle the window server interruptions with the Direct Screen Access framework. This way you get the best of the both worlds: Draw directly to the screen and still won't interfere the window server. In this case you just have to make sure you are using the whole screen - or use only the areas that you reserve from the window. You also have to stop drawing whenever DSA clips region.. So in a way you are a bit more restricted... But this works.