slow update, while blitting!!!

[rs_chikin]

Hi!

I'm creating simple graphics engine. Working with context is very fast. But flushing it onto frame buffer is very slow ~10 fps on emulator and ~20 fps on phone 7650

for updating i'm using CDirectScreenAccess and deriving CTimer

code:

void CDSAEngine::RunL()
{
iDirectScreenAccess->ScreenDevice()->Update();

// work with offscreen
.........
// end work with offscreen

iGc->BitBlt(TPoint(0,0), iOffScreenBitmap);
After(TTimeIntervalMicroSeconds32(KGenerationInterval));
}

KGenerationInterval = 10;


thanks

[etunkelo]

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
iDirectScreenAccess->ScreenDevice()->Update();

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.

Eero
Forum Nokia

[rs_chikin]

hello again!

problem is not solved

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

strange thing:

if iDirectScreenAccess->ScreenDevice()->Update();
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!!!

what's up ?

thanks!

[etunkelo]

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...


Hope this helps.

Eero

[rs_chikin]

I obtained acceptable speed of drawing fullscreen bitmap - great thanks! Finland rules

i'm porting my 3d engine to 7650 and because of it I have no need to draw already prepared bitmap, but have to build it pixel by pixel...

could you be so kind and suggest me the best way to do it... the fastest way

or any other way of pixel output (may be direct access to video frame memory UserSvr::ScreenInfo() or smth ?)

i tried to use TBitmapUtil, but it's too slow

[etunkelo]

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.

Eero
Forum Nokia