Hi Nick,
I don't have an exact solution for you, but I've run into some
similar problems that might be related...
>I'm working on a graphics-related application. It will support things like
>zooming and panning. As such, I would like to use double buffering to
>reduce the screen flicker while panning. However, I'm having lots of
>problems related to drawing to an offscreen window. Here's the general
>idea:
>
>1) Set the screen depth to the maximum supported by the device and save the
>original depth
> WinScreenMode ( winScreenModeGet, &width, &height, &depth,
>&enableColor);
> mSavedDeviceScreenDepth = depth;
> WinScreenMode ( winScreenModeGetSupportedDepths,
>&width,&height, &depth,
>&enableColor);
> .
> . // calculate depth
> .
> WinScreenMode (winScreenModeSet, NULL,NULL, &depth, &enableColor);
>
>2) Grab the bitmap from our database
>
>3) Draw the bitmap on screen
> WinDrawBitmap( bitmapP, rect->topLeft.x, rect->topLeft.y );
>
>4) Create an offscreen window and draw the bitmap offscreen
> if (!mOffscreenWindow)
> mOffscreenWindow = WinCreateOffscreenWindow
>(mWindowBounds.extent.x,
>mWindowBounds.extent.y, screenFormat, &err);
>
> winH = WinSetDrawWindow (mOffscreenWindow);
> WinDrawBitmap( bitmapP, 0, 0);
> WinSetDrawWindow (winH);
>
>5) Then while panning, copy the bitmap from offscreen on to the screen
> WinSetClip(&mWindowBounds);
> WinCopyRectangle (mOffscreenWindow, 0, &mWindowBounds, newX, newY,
>winPaint);
> WinResetClip();
>
>6) On appStopEvent, restore screen depth to the orignal depth
> if (mSavedDeviceScreenDepth) {
> WinScreenMode ( winScreenModeGet, NULL,NULL, NULL,
>&enableColor);
> WinScreenMode ( winScreenModeSet, NULL,NULL,
>&mSavedDeviceScreenDepth,
>&enableColor);
> mSavedDeviceScreenDepth = mDeviceScreenDepth = 0;
> }
>
>Depending on what ROM I am running on, copying the pixels from offscreen to
>screen gets fouled up. The pixels look as if they're inverted somehow.
1. If your bitmap doesn't contain a color table, then you might not
get the colors you're expecting. In my case, I was creating a 1bpp
bitmap on the fly, and needed to specify a two entry black&white
color table for use with the bitmap, otherwise the WinCopyRectangle
call would blit my white pixels with the foreground color.
Assuming that the bitmap does have a color table, then calling
WinCreateOffscreenWindow will create a bitmap with no color table,
and make that the bitmap for the new window. So blitting from your
bitmap to the window will use the system color translation table if
the depths of the two images aren't the same (which is what I'm
guessing is the case). That's as far as I've looked down the calling
chain - so I don't have a good suggestion, other than trying to
create an off-screen window which uses a bitmap that contains a color
table.
2. When calling WinCopyRectangle(screen, off-screen) and the
off-screen window uses a bitmap without a color table, then Palm OS
3.5 will accidentally dispose of the system color table, and a
subsequent call will die in Poser. I think this same situation might
occur in the inverse case as well.
>Also when restoring the saved screen depth upon exiting, I usually get an
>error that I have written to unallocated memory, causing a fatal exception
>on a real device. However, if I do NOT draw offscreen, I don't have any
>problems when restoring the saved screen depth. I tried running on
>different ROMS, and here is what I have found:
>
>ROM Version Copying offscreen->screen
> Restoring screen depth
>----------------------------------------------------------------------------
>-------
>35-ezdbg displays incorrectly
> error
>35-colordbg displays incorrectly
> no error
>40-fulldbg "Bad Window" error when drawing to
>screen n/a
>40-VZcolordbg displays correctly
> no error
>
>I'm not sure if the problem is related to drawing offscreen, or copying from
>offscreen to screen. But I do know that the images always look correct when
>they are drawn to the screen. Any ideas?
So this could be another variation of problem #2 above.
Also, if you've called FrmCloseAllForms before trying to restore the
screen depth, then the draw window has been set to 0x8000000 on debug
ROMs, and there's a bug in the 3.5 OS where it will try to use this
window when handling a depth change in the WinScreenMode() code.
The work-around is to either make sure you've got a valid draw window
before calling WinScreenMode, or don't worry about restoring it on
exit from your app, since the OS will do this for you.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
