A big thank you to all of you who replied!
First of all, using OS 3.5 - I think - would be pushing the limits... What I
know of there is no upgrade for old device yet so this would cut off a very
large percentage of the market.
Thus, I'm back on square one. I've tried normal double buffering but it
flickers because of the delay that WinCopyRectangle() inflicts. And yes, I
have to copy the whole screen because the app draws certain graphic shapes
as a result of user input(i.e. penDown events).
I was thinking - and have spent the last two hours trying - of saving all
graphics as struct objects in a linked list:
struct drawObject {
drawType type;
short x1, y1, x2, y2;
int thickness, radius;
Boolean fill;
};
and then when the app is repainting the screen it just processes the linked
list and draws the graphics.
WinSetDrawWindow(offscreenBuffer);
switch (aDrawObject.type) {
case line: WinDrawLine(aDrawObject.x1, aDrawObject.y1, aDrawObject.x2,
aDrawObject.y2); break;
....
}
WinSetDrawWindow(scrnBuffer);
WinCopyRectangle(offscreenBuffer, scrnBuffer, &drawArea, 0,0, scrCopy);
But this method was too slow and when the linked list contained about 100
items further development of this method seemed futile.
Is there any way of doing this right? Or am I going to blame the little 16
Mhz processor? It just doesn't feel right, blaming something so weak and
fragile :)
Do I have to get into assembler stuff ( that I don't know anything about for
that matter)?
Thanks,
Nils �gren
> From: "Peter Epstein" <[EMAIL PROTECTED]>
> Newsgroups: palm-dev-forum
> Date: Wed, 1 Mar 2000 17:24:49 -0800
> To: palm-dev-forum
> Subject: Re: Double buffering....
>
>
> "Nils �gren" <[EMAIL PROTECTED]> wrote in message
> news:3650@palm-dev-forum...
>
>> I'm using simple double buffering when drawing; first I draw everything in
> a
>> offscreen WinHandle and then I copy the offscreen into the screenBuffer.
>> It works well, almost. It's still flickering! I believe this is because of
>> the time it takes for my Palm V to copy the offscreen to the screen...
>
> If you're willing to require OS 3.5 or later for your application, you can
> use the new WinScreenLock and WinScreenUnlock API to effectively switch the
> screen hardware to point to a different chunk of memory, giving a very fast
> switch from the old state to the new state. By passing winLockDontCare, it
> is possible to avoid the cost of copying the entire screen each time, but
> you'll have to add code to keep track of three different states in the
> animation rather than just two. If you want to support older OS versions,
> you could build your own wrapper functions that would use the new API when
> it is available and would copy from an offscreen window when it isn't. Note
> that copying bitmaps is slower on color devices because of the greater
> screen depth, so if you're having trouble with a Palm V, it'll likely be
> even worse on a IIIc. You should avoid copying the entire offscreen window
> to the screen, and only copy the area(s) that changed. Coalescing many small
> areas into one large one will improve performance in some cases, but not if
> the unchanged area is large. You can use POSE to profile your displaying to
> find an approach that works for your application on all the devices you want
> to support.
> -
> Peter Epstein
>
>
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
