Quickwin/StandardGraphics and bitblt

[dboggs]

I need to draw a (series of) somewhat complicated "movie frame" images in a Quickwin or Standard Graphics viewport, then flash them rapidly to another viewport. I can do this by drawing it in a scratch viewport, putting it to memory in an array using GETIMAGE, and then putting it on screen in a different movie viewport using PUTIMAGE.  I wish the user to ignore the drawing operation--which takes .01 seconds or so to create and involves blanking out various areas resulting in "flicker"--and watch only the destination viewport, which can appear as a smooth animation movie. In a Windows application this would probably be done using the API bitblt routine, which very rapidly copies a block of pixels from a rectangle in the source device context to a corresponding rectangle in the destination context. Typically this would be from a memory device context (NOT display memory) where it is hidden, to a window device context (display memory) where it appears in a window. GOOD!

GETIMAGE and PUTIMAGE work very fast and are probably based on the bitblt API function. Unfortunately. as far as I can see the image can only be drawn to an onscreen viewport, which destroys the concept of animation. In Quickwin I can awkwardly get around this by putting the scratch viewport in a child window that is minimized, but I really want to do it in a Standard Graphics application to avoid the Quickwin MDI screen clutter.

If there were some way to hide the scratch viewport from the user, that would do it. Am I missing something about the way Quickwin viewports can operate? Is there some way to trick the viewport to exist in regular memory instead of display memory, perhaps using an API function? Note I do not want to pull off the whole animation thing in a Windows project, as that is beyond my capabilities horizon.

If Intel EVER plans more work on Quickwin (which I think they should), this would be an excellent extension to add to the getimage routine, along with stretchblt.