🚀 go-pugleaf

in article <1159@tuura.UUCP>, risto@tuura.UUCP (Risto Lankinen) says:
> 
> jrv@demon.siemens.com (James R Vallino) writes:
> 
> 
>>The basic problem is that before anyone overwrites part of my client display
>>memory, I have to save the pixels which will be overwritten.  I don't have
>>another copy of the pixel data.  It has been generated by a coprocessor ...
> 
> Hi!
> 
> Wouldn't one solution then be to simply have the other copy around?  Plotting
> to a compatible bitmap might even be faster than directly to the client area,
> because it uses system memory (instead of display adapter's, which is slower
> in many cases althou' maybe not generally).  Also, the window invalidization
> (sp?) could be done less frequently.
> 
> Then there's a window style, <something>_SAVEBITS, which could be used for
> the window's own dialogs to make them automatically memorize whatever they
> write over upon initially popping up.  I'm also under the impression, that
> the Windows' standard menus have this style flag set.
> 
> Terveisin: Risto Lankinen
> -- 
> Risto Lankinen / product specialist ***************************************
> Nokia Data Systems, Technology Dept *  2                              2   *
> THIS SPACE INTENTIONALLY LEFT BLANK * 2 -1 is PRIME!  Now working on 2 +1 *
> replies: risto@yj.data.nokia.fi     ***************************************

Windows applications must be capable of restoring their images.  The 
CS_SAVEBITS style does not guarantee that the window will be saved.  The
display driver will try to save the area but if it needs the memory for 
something else before the saved area is restored, it will throw it away and 
tell Windows to have the application redraw the no longer saved area.  This
applies to Windows' standard menus as well as user defined windows.

Good luck,
Greg