Mixing window system and graphics operations

Thread View: comp.windows.misc

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Sandeep Mehta Tue, 14 Jun 1988 19:56

#952

Author: Sandeep Mehta
Date: Tue, 14 Jun 1988 19:56

25 lines
1787 bytes

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

Re: Mixing window system and graphics operations

#954

Author: Michael Sierchio
Date: Thu, 16 Jun 1988 18:47

19 lines
1237 bytes

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!sierch

Re: Mixing window system and graphics operations

#955

Author: Sandeep Mehta
Date: Mon, 20 Jun 1988 13:14

27 lines
1912 bytes

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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads