sxm@bebop.philips.com (Sandeep Mehta) (06/15/88)
I wonder if anybody else had faced the following problem, and found even a partially optimal solution. I am writing some 3D object modelling software which needs to be interactive i.e. I want control over objects displayed in a window using window system toolkit primitives (e.g. buttons, scrollbars, menus etc.). What I have noticed with both the packages I tried this experiment on (SunCore and PHIGS based FIGARO) is that the application take over control of the entire current window thus limiting any user interface interaction. I believe the graphics packages are implemented using the lower level Pixrect library (on Sun w/s'). My solution to this was to write the interface and object modeller as client-server processes thus partially separating the graphics package operation from the window system. The problem of course is the overhead I face with inter-process communication whether I use file or pipe I/O considering the volume of 3D data being processed ! I would imagine that I should be able to initialize and perform graphics operations in a subwindow just as I can from the root window. Any ideas would be helpful. Thanks ! sandeep -- Sandeep Mehta uunet!philabs!bebop!sxm Philips Laboratories sxm@philabs.philips.com
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (06/18/88)
[ My Organization: name today may be applicable here. ] In article <3647@briar.Philips.Com> sxm@bebop.philips.com (Sandeep Mehta) writes: >What I have noticed with both the packages I tried this experiment >on (SunCore and PHIGS based FIGARO) is that the application take over control >of the entire current window thus limiting any user interface interaction. >I believe >the graphics packages are implemented using the lower level >Pixrect library (on Sun w/s'). [ ... ] > >I would imagine >that I should be able to initialize and perform graphics operations in a >subwindow just as I can from the root window. > I don't know about SunTools terminology, but.... Are you saying that SunCore and FIGARO blitz the root window (which I take to mean SunTool's full-screen backdrop window)? Hmmmm. Please excuse me while I use some Amiga terminology on you. SunTools doesn't have Amiga-style "screens", so I'd recommend that you force SunCore or FIGARO to run in the equivalent of a super-bitmap window. This is a window whose bitmap is stored and manipulated in an off-screen memory area (malloc() that sucker :-) ), a portion of which is copied to the on-screen window. Graphics operations in this window are specially handled such that the master bitmap is synchronously updated with the on-screen window. So you'd render into the master bitmap, and periodically copy the visible portion to your on-screen window. You'd probably put scroll bars on this window so the user could pan around the larger master bitmap. And then you open a second window with buttons and gadgets and menus and requesters and all that neat stuff, and use it as the user's control window. Again, I don't know if SunTools provides for this, but you may wish to consider the concept in general, and see if you can't "fake it". Assuming you like the idea, that is... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Hmm, you're right. Air is made up of suspended meat loaf." -- Josh Siegel
garry@batcomputer.tn.cornell.edu (Garry Wiegand) (06/20/88)
In a recent article sxm@bebop.philips.com (Sandeep Mehta) wrote: >I wonder if anybody else had faced the following problem, and found even a >partially optimal solution. I am writing some 3D object modelling software >which needs to be interactive i.e. I want control over objects displayed >in a window using window system toolkit primitives ... In the course of porting Hoops to the Mac we noticed that allowing the graphics library and the user program to share the use of the screen/window wasn't very hard - most window systems seem to be fairly clean in keeping popups and such from different sources out of each other's hair. However, as you noticed, figuring out how to untangle the stream of events coming back is a tougher problem. What we ended up having to do was to create a new kind of event in our system - a generic "special" event - and then we arranged to queue one of those back with appropriate info to the user program whenever an "unexpected" windowing system event is encountered. It would be nice to be able to work the other way too - to let the user program be in charge of the window system event queue and choose to hand some things over to Hoops for interpretation... I'll see what we can do :-) (The Mac is just the case at hand - we'll have to do the same for our new releases on the Sun, on X, on the Presentation Manager, etc etc etc ) garry wiegand (garry@oak.cadif.cornell.edu - ARPA) (garry@crnlthry - BITNET)