Quick reactions on graphics post

[bill One]

Jonathan S. Shapiro wrote:


> These are brief responses -- I'm working on something else at the
> moment.

  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
  for completeness.

= = = = = 

> [...]

> 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
  housekeeping.
  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
  entity.

  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.