Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!o.gp.cs.cmu.edu!spot
From: spot@CS.CMU.EDU (Scott Draves)
Newsgroups: comp.arch
Subject: Re: Let's pretend
Message-ID: <SPOT.90Dec24144102@WOOZLE.GRAPHICS.CS.CMU.EDU>
Date: 24 Dec 90 19:41:02 GMT
References: <3042@crdos1.crd.ge.COM> <450@lysator.liu.se>
	<1990Dec23.093537.18481@ncsuvx.ncsu.edu> <28774@mimsy.umd.edu>
Sender: netnews@cs.cmu.edu (USENET News Group Software)
Organization: School of Computer Science, Carnegie Mellon University
Lines: 65
In-Reply-To: chris@mimsy.umd.edu's message of 24 Dec 90 14:49:24 GMT

In article <28774@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:

   Depending on how you define a `window', future hardware might have to
   handle numbers on the order of 10,000 windows.  (X11 was originally
   designed to make each individual window cheap, unlike SunView; as time
   passed the windows got `fatter' and now in addition to `widgets', each
   of which is a window, there are toolkits with `gadgets', which are not.

X11 Windows are still as small and cheap as they ever were.  The
reason Motif uses gadgets is that widgets are fat, especially its
widgets.  In my Motif code I never use gadgets and find performance to
be adequate, and my code does a lot of creation and destruction of
widgets, which is their worst case.

   The window system (as a whole, however it is built)
   must provide each `window user' (application or whatever) the illusion
   that it has an arbitrarily large and arbitrarily perfect screen all to
   itself.

Well, I don't think arbitrarily large fits in with the rest of this,
but yes.  This is basically what PostScript does (with the addition of
abstract coordinates).

  (This is another reason X11 is wrong.)

I don't think statements like that are warranted.  For something that
is "wrong" X11 is very successful and widely used.

My understanding is that X isn't intended to be very abstract,
abstract colors and coordinates are the place of an extension or a
toolkit.  Unfortunately, no such beast exists, which is a shame; I
think it would be very popular.

Similarly, X doesn't specify a user interface, that's the place of
Motif.  There's a lot to be said for this modularity.

   [ refresh should be handled by the window system.  apps invisibly
     draw into offscreen buffers and blit to the screen as necessary.
     The extra memory is well spent because it saves code in every
     application, and saves developement time. ]

I disagree with your analysis.  The amount of extra code and effort
that needs to be put into each application is near zero.  You are
orders of magnitude away from balancing the cost of the hidden
windows.  In any case relatively few unix programs interact with the
window system; most run in terminals (this may eventually (hopefully?)
change).

I really like what the NeXT window system does.  It gives an
application three choices for handling refresh.  The window system
either 1) saves bitmaps and blits to refresh the screen.  2) saves the
postscript and rerenders to reresh the screen.  3) calls the app.

There are many cases where saving the bits is ridiculously
inefficient.  Two examples: 1) the window is displaying a bitmap
image, so the application already has its own offscreen buffer.  2)
the window is sparse, i.e. mostly background.

I have no qualms about spending memory, but you must decide if the
alternatives warrent it.
--

			IBM
Scott Draves		Intel
spot@cs.cmu.edu		Microsoft