Quick reactions on graphics post
Fri, 01 May 1998 13:30:58 -0600
Jonathan S. Shapiro wrote:
> These are brief responses -- I'm working on something else at the
I can only imagine what a detailed responce would
be like. :)
> [... Lots of good stuff I'll have to think on ...]
> We should also look at the windowing primitives provided by MGR, which
> was done at BellCore.
Thanks for the pointer... it is proving interesting reading.
As a practical manner it looks like porting MGR would be much
less effort than building anything from the ground up for EROS.
MGR already has tested VGA support. And it has already been
ported to several different platforms so its porting rough
edges have already been worn off.
So... The points below are probably moot, and I'm commenting
= = = = =
> In message <3548CBCD.4B55@key.cc.utah.edu>, bill One writes:
> [I distinguish between graphics manager and window manager partly to
> avoid confusion with existing terminology and partly because they
> really are different. The job of the graphics manager is to
> virtualize the graphics subsystem. The job of the window manager is
> to present an interface and perhaps some interaction policies.]
There may be philosophical issues here...
My philosophical view:
To me the job of the window manager is to dole out visible
real estate, and deal with overlaps, multiple devices, and
The window manager owns the screens (frame buffers, etc).
It makes up visible regions, and routines can do graphics
only to those visible regions they are handed. (With the
window manager possibly having to make multiple calls on
various graphics drivers to handle windows that overlap
screens or devices.)
It is the ebodyment of the interaction policies, but
it is only secondarily an interface.
The graphics manager handles graphics into (just) the real
estate that it is given, on behalf of the user. And in my
experience is best kept unaware of interaction issues.
I've helped write systems where the window manager's function
has windows overlapping multiple devices... The ones that have
been cleanest for me are those where the graphics deal with
visible regions as primitive (an not the raw frame buffer)
and the window manager doles out visible regions.
Possibly this is a terminology issue... but since the graphics
depend on the Window manager's data structures, and not the
other way around, I take the manager as the more primitive
I have seen projects where the window manager filtered
everything and also did clipping, and graphics drivers
did none... simplier device drivers,
but uglier window manager.