jrv@demon.siemens.com (James R Vallino) (04/30/91)
I'm scoping out an image processing application which I want to be a Windows application. (The marketing folks would like this a lot.) The frame buffer boards which I am looking at are at least 1k x 1k and have 34010 or 34020 processors on them. All of them have TIGA drivers available. I will also create extensions to the TIGA interface to perform my image processing tasks. In looking at the implications of using Windows I have come upon some issues for which I don't have any answers. (If while reading this you think of all the other things which I missed let me know that too!) The major problem I am seeing is the interaction between Windows thinking it owns the display and my image processing routines thinking they own it. Here are some of the ideas which I have come up with for my user interface: - use one monitor for the Windows user interface stuff and a second one for the frame buffer which has my pixel data. This really won't fly. - bag the marketing "benefit" and just create a DOS application. Roll my own user interface menus, etc. We've done that before and can do it again. - use the VGA pass through mode to create two monitors on one. This also won't fly because some of the user interaction requires the image to be visible. VGA pass through gives you one (Windows) or the other (image data) on the single screen but not both at once. - only allow my application to be run maximized and force it to be minimized as soon as it losses the focus. This can probably be done but does not seem like a very good user interface to me. - use a frame buffer with overlay planes. The Windows interface writes to the overlay planes. I would have to reserve one color for transparent where I want my pixel data to show through in the client area for my application. This costs more for my display board. Ignoring that, there is the potential for a problem if another windows application uses the "transparent" color inadvertently. Parts of my image data would bleed through that applications window area. - venture into the unknown and attempt to run my algorithms on my image within a Windows window. First, can a Windows application cleanly get access to one of the extensions I have added to my TIGA interface? Secondly, I have not seen an obvious way in which Windows will tell an application when part of its client area is being overwritten. It assumes that the application can always restore its client area when the WM_PAINT message is sent. For me this is not the case. Some of the pixels stored in the display buffer are my only copies of the processed data. Before Windows jumps in and overwrites any of them I have to be able to save them. I would have to create a shadow copy of the processed data in non-displayed memory on the display board. At that point I must interrupt any processing which the 34010/20 is performing. I would need a board which allows an application to generate an interrupt on the 34010/20. I will either have to stop all image operations at this point or have enough smarts in my algorithms to continue work with some data in displayable memory and the overwritten data which is now in a non-displayed piece of display board memory. If anyone else is pondering, struggling with an application similar to this it would appreciate any comment, condolences, words of advice, words of warning, etc. Thanks for any information. -- Jim Vallino Siemens Corporate Research, Inc., Princeton, NJ jrv@demon.siemens.com princeton!siemens!demon!jrv (609) 734-3331
ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (05/01/91)
About handling windows overwriting part of the client area - consider saving the entire image (if possible - how many bits) in a Windows bitmap. Then you can bitblt it to the screen on receipt of a WM_PAINT message, without having to recalculate the image or play tricks with memory on your graphics board... Terrell
Chris_Graham@f344.n632.z3.fidonet.org (Chris Graham) (05/10/91)
* Original <30 Apr 91 00:46:07> was from James R Vallino to All > JR: From: jrv@demon.siemens.com (James R Vallino) > JR: Reply-To: jrv@demon.siemens.com > JR: Newsgroups: comp.windows.ms.programmer,comp.graphics > JR: If anyone else is pondering, struggling with an application > JR: similar to this > JR: it would appreciate any comment, condolences, words of advice, > JR: words of > JR: warning, etc. Phillips have done a windows interface as a driver for their electron microscope. I've seen a picture of the image that it can throw out, and I was quite impressed. You may wish to check it out. -Chris PS: If you see this message, please send me a message back, as I'm not sure that this will get through to the unix net. I await your reply.