awm@shamash.cdc.com (Allan Magnuson) (12/18/90)
Let me describe my problem and see if anyone can offer me a solution (I'm sure that some of you may have the same one). I work on a large CAD/CAM suite of programs that runs with GL. We have a user interface in GL. It doesn't look great and isn't portable, but it is fast because we can put it in the overdraw planes to avoid a REDRAW token being placed in the window with the users geometry. Users have *very* large parts (those cars can get pretty big), so a REDRAW in the main window every time something pops up, down or resizes can be an extreme problem, even with bounding box clipping (or bounding sphere clipping, or whatnot), just because of the size of the parts. It actually isn't real bad, the GL is *very* fast, but users will, naturally, create parts as big as the machine can handle so they can get their work done faster. Now the problem: We would very much like an interface in something that is X based, like MOTIF. We know that right now, MOTIF and GL windows cannot co-exist, but in the future they will be allowed to. This is great, our development of a nice, portable, interface will probably take until the 4.0 release comes out. But we can't sell the idea to anyone unless we can solve this REDRAW problem. We can't have an interface that causes redrawing of all the users geometry. We thought about saving the bit image off the screen when you pop something in MOTIF up, asking the pipeline what is on the screen, and a number of other things, but nothing seems to be safe or clean. What we would really like to do is be able to pop up our interface in a completely different set of bitplanes, as to avoid a REDRAW token. Maybe this isn't even the best idea, any suggestions? Am I missing something obvious? By the way, the SGI workstations are really nice pieces of work. Eric Swildens Control Data Corporation awm@shamash.cdc.com (using Al's account temporarily :-) )
msc@ramoth.esd.sgi.com (Mark Callow) (12/22/90)
In article <29333@shamash.cdc.com>, awm@shamash.cdc.com (Allan Magnuson) writes: |> interface in GL. It doesn't look great and isn't portable, but it is fast |> because we can put it in the overdraw planes to avoid a REDRAW token being |> placed in the window with the users geometry. |> . |> . |> . |> Now the problem: We would very much like an interface in something that is |> X based, like MOTIF. We know that right now, MOTIF and GL windows cannot |> co-exist, but in the future they will be allowed to. This is great, our |> development of a nice, portable, interface will probably take until the |> 4.0 release comes out. But we can't sell the idea to anyone unless we can |> solve this REDRAW problem. We can't have an interface that causes redrawing |> of all the users geometry. We thought about saving the bit image off the The X server in release 4.0 will support an overlay visual so you will be able to put those motif thingies in the overlay planes. However using the overlay planes limits your color choices. Also in 4.0 I think a GL application will finally be able to find the bounds of the damaged region when it receives a REDRAW. This let's your app. just repaint the piece that was covered by the whatever UI thingy popped up. Incidentally I recommend you not use the OSF/Motif toolkit. It's a pig. Currently the minimum application size in 1 megabyte and it takes 5 seconds for the app. to start up. We will do our best to improve those figures before 4.0 is released but it's largely out of our control. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "Spirits of genius are always opposed by mediocre minds" - Albert Einstein
mg@ (Mike Gigante) (12/23/90)
msc@ramoth.esd.sgi.com (Mark Callow) writes: >Incidentally I recommend you not use the OSF/Motif toolkit. It's a pig. >Currently the minimum application size in 1 megabyte and it takes 5 seconds >for the app. to start up. We will do our best to improve those figures >before 4.0 is released but it's largely out of our control. Just to clarify this: Are you saying that this is an interim problem that is likely to dissapear? Or are you saying it is inherent in OSF/Motif? Mike Gigante RMIT
msc@ramoth.esd.sgi.com (Mark Callow) (01/03/91)
In article <mg.661898161@godzilla>, mg@ (Mike Gigante) writes: |> msc@ramoth.esd.sgi.com (Mark Callow) writes: |> |> >Incidentally I recommend you not use the OSF/Motif toolkit. It's a pig. |> >Currently the minimum application size in 1 megabyte and it takes 5 seconds |> >for the app. to start up. We will do our best to improve those figures |> >before 4.0 is released but it's largely out of our control. |> |> Just to clarify this: |> |> Are you saying that this is an interim problem that is likely to |> dissapear? Or are you saying it is inherent in OSF/Motif? |> I'm saying its a problem inherent in the OSF/Motif toolkit and the folks working on it here will do their best to mitigate its impact. Only OSF can really solve Motif's size and performance problems. One of our people who is noted for writing lean and super fast code was so disgusted he was moved to write his own small toolkit for a job he had to do. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "Spirits of genius are always opposed by mediocre minds" - Albert Einstein