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
sierch@well.UUCP (Michael Sierchio) (06/17/88)
It seems to me, and has for some time, that one of the major defects of
PHIGS and GKS, etc. is that they provide the user interface support that
they do -- they simply aren't designed for multi-taking workstations in
which the input and output focus are the responsibility of a special
process (the Notifier, etc). They were designed for plotters, dumb
serial graphics terminals, and film-recorders.
As we move into Network Windowing Systems on cheaper and faster wk-stations,
these annoying vestiges make life difficult -- why use PHIGS's hierarchical
database when your LAN offers a realtional engine (hardware, etc)??? Why
use GKS when all you want is to render a metafile image in a window under
X11???
--
Michael Sierchio @ Small Systems Solutions
sierch@well.UUCP
{pacbell,hplabs,ucbvax,hoptoad}!well!sierchsxm@philabs.Philips.Com (Sandeep Mehta) (06/20/88)
In article <6300@well.UUCP> sierch@well.UUCP (Michael Sierchio) writes: > >It seems to me, and has for some time, that one of the major defects of >PHIGS and GKS, etc. is that they provide the user interface support that >they do -- they simply aren't designed for multi-taking workstations in >which the input and output focus are the responsibility of a special >process (the Notifier, etc). They were designed for plotters, dumb >serial graphics terminals, and film-recorders. > I think the reason most graphics packages seem unsuitable for graphics workstations is because the standards definition makes them so. I keep asking my PHIGS package vendor why they insist on using FORTRAN to implement their software, and they best answer I got was "historical reasons", "the standard probably specifies FORTRAN langauge bindings", and of course "majority of our customers still use FORTRAN". Funnily enough the F77 compiler on the Suns is written in C (as far as I know) which allows to me carry on in C and work around the mixed language binding problems. I think the standards committees should acknowledge the advent of the era of high-end graphics multi-tasking workstations. sandeep -- Sandeep Mehta uunet!philabs!bebop!sxm Philips Laboratories sxm@philabs.philips.com