Hi Peter,
I've just been benchmarking the WinScreenLock/Unlock() functions against my
custom screen-copying code (basically some 68000 for copying the whole
screen as fast as possible). I've been using POSE, 'cos we've not got any
IIIc's in the UK yet, but the results were rather disappointing:
Astraware CopyScanlines(): 48.6s for 1000 frames
WinScreenLock(): 48.7s for 1000 frames.
I was doing 'WinScreenLock(winLockDontCare)', so my conclusion has to be
that PalmOS is copying the screen from the temporary area to the real one in
WinScreenUnlock(). Anyone any evidence either way?
Shame that, I was hoping to squeeze a bit more performance out of Zap!2000
colour...
Kind regards,
David
---
David Oakley - [EMAIL PROTECTED] - ICQ 9610512
partner, Astraware - http://www.astraware.com/
Take part in the Palm colour beta: email [EMAIL PROTECTED]
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter
> Epstein
> Sent: 02 March 2000 01:25
> To: Palm Developer 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
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
