jrv@demon.siemens.com (James R Vallino) (05/02/91)
Continuing to persue my previous problem with an image processing task under Windows, I have a much more Windows specific question. Does a window know when it is being overwritten? The potential exists whenever the input focus is lost. The focus will be lost whenever another application is brought up on top of my client area. This is also true when my application brings up a dialog box. For drop down menus and child windows I don't think that is true. I have control over when the child window will appear. I don't recall any message sent just before a menu is dropped. 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 on the display card running some algorithms on my image data. I could keep a shadow copy of the data in extra memory on the display card. But I will still not know if it is OK for the display coprocessor to write the data to the diplay area if I don't know that I own all of the pixels in my client area. I think I'm going to have to bag the idea of using Windows without adding more cost to my display board to get some extra hardware support. Thanks! -- Jim Vallino Siemens Corporate Research, Inc., Princeton, NJ jrv@demon.siemens.com princeton!siemens!demon!jrv (609) 734-3331
wolf@netcom.COM (Buckskin Tech.) (05/04/91)
<in response to a question about being notified when a window is about to be overwritten> Yes, it's true that it's possible for the window to be overwritten whenever you lose focus. Therefore, it's a good idea to snapshot any dislay data just before you lose focus. As for menus, there is a message (WM_INITMENUPOPUP) that is sent immediately before a menu is displayed. You can try using a WM_MEASUREITEM for each item in the menu about to be displayed to determine the area that will be obscured. You're really only allowed to write to your entire client area if you use the display context you get from Windows. The DCs you can get all go through the installed video driver. This driver expects to be aware of any and all changes being made to the display, and have veto power over every change. For hardware display updates, you'll probably need to have a special video driver that can accomodate the display from the coprocessor. There are some real-time video cards for Windows that use this technique, I believe. - Wolf
johnm@spudge.UUCP (John Munsch) (05/04/91)
In article <59847@siemens.siemens.com> jrv@demon.siemens.com writes: >I could keep a >shadow copy of the data in extra memory on the display card. But I will >still not know if it is OK for the display coprocessor to write the data to >the diplay area if I don't know that I own all of the pixels in my client >area. This is exactly what I would suggest you do. Write the data not to the screen but to a data storage area of your own. Windows does not consider the screen to be a storage medium, as far as it is concerned you should normally be able to regenerate any display that is worth displaying. What you are leaving out of your consideration is that you normally do not worry about other windows (either child or other programs) when you output to your own window. Output from primitives ranging all the way from SetPixel() (ugh...) to SetDIBitsToDevice() is going to clip itself so that it will not overwrite child windows (provided the window you write to was created with WS_CLIPCHILDREN) and will NEVER overwrite other windows that just happen to be laying across part of it. It simply is not a concern for you. I wrote a picture display program without ever having to consider how other programs windows might intersect mine and it works very well. John Munsch
shap@bunker.isc-br.com (Joseph D. Shapiro) (05/06/91)
In article <59847@siemens.siemens.com> jrv@demon.siemens.com writes:
: Does a window know when it is being overwritten? The potential exists
: whenever the input focus is lost. The focus will be lost whenever another
: application is brought up on top of my client area. This is also true when
: my application brings up a dialog box. For drop down menus and child windows
: I don't think that is true. I have control over when the child window will
: appear. I don't recall any message sent just before a menu is dropped. 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 on
: the display card running some algorithms on my image data. I could keep a
hi. Somebody else already posted about the message you get when a menu
is about to drop. But did you know that the pixels under the menu are
automatically saved and restored? This gets a little more difficult if
you continue to draw on the window when the menu is down, and it might
also be confounded by your video processor, but take it for what it is
worth.
--
__--__--__--__--__--__--__--__--__--__--__--__--__--__--__--__--__--__--__--__
Joe Shapiro "My other car is a turbo...
ISC-Bunker Ramo ...too."
{decvax,yale,philabs,oliveb}!bunker!shapristo@tuura.UUCP (Risto Lankinen) (05/07/91)
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 ***************************************
Kent_Stewart@f50.n347.z1.fidonet.org (Kent Stewart) (05/09/91)
> Does a window know when it is being overwritten? The > potential exists > whenever the input focus is lost. The focus will be > lost whenever another James, I think that is the main reason for wm_paint. It tells a window to repaint when it is the main window. You bring a window forward by it rewritting the screen. Which Siemens group are you in? I'm part of the KWU group called ANF. Kent
chrisg@microsoft.UUCP (Chris GUZAK) (05/11/91)
All windows apps must be able to regenerate their display at any time. You must have an internal representation of you data that you can use to regenerate your display. (ie, you can't save your state on the display device) If you design your program assuming you can take things off the display it will not work. It will appear to work for a while, but when you get in low memory conditions it will fail (windows won't restore what is under popups, etc, it will ask you to regenerate it). In general, there is no way to know if you are covered up (especially in future versions). Chris In article <19209@bunker.isc-br.com> shap@clunker.UUCP (Joseph D. Shapiro) writes: >In article <59847@siemens.siemens.com> jrv@demon.siemens.com writes: >: Does a window know when it is being overwritten? The potential exists >: whenever the input focus is lost. The focus will be lost whenever another >: application is brought up on top of my client area. This is also true when >: my application brings up a dialog box. For drop down menus and child windows >: I don't think that is true. I have control over when the child window will >: appear. I don't recall any message sent just before a menu is dropped. 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 on >: the display card running some algorithms on my image data. I could keep a >
gregj@cpqhou.uucp (Greg Judkins) (05/14/91)
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