🚀 go-pugleaf

In article <MARCA.93Feb23190828@wintermute.ncsa.uiuc.edu>, marca@ncsa.uiuc.edu (Marc Andreessen) writes:
|> In article <DSCHIEB.93Feb22173944@muse.cv.nrao.edu>
|> dschieb@muse.cv.nrao.edu (Darrell Schiebel) writes:
|> 
|>    > I think the speed must depend on the style of use.  I've found on my
|>    > sparc 2 that when using one screen per buffer, once I've gotten 6+
|>    > buffer/screens, lemacs gets unacceptably slow when switching screens,
|>    > to the point where it takes several seconds for a screen to raise.
|> 
|>            I too have experienced this. If there are any solutions, I'd
|>            appreciate hearing about them!
|> 
|> Part of this is due to Xt overhead.  Epoch wins big on performance by
|> doing its own graphics/windowing directly, I think.
|> 
|> How much is that menubar worth?  :-)
|> 
|> Marc

Actually, the problem Doug describes is NOT due to Xt overhead.  It is due to
some other problem in the screen redraw and focus functions.

For the most part, lemacs operates at speeds acceptable for interactive use.
Some degradation in speed is due to the order in which objects are displayed.
Screen creation, for example, would be faster if the menubar were placed
before the screen was mapped.  With proper widget construction, you probably
would not notice the difference in speed; at least you would not notice it on
a Sparc.  Lucid emacs does take a little longer to display the initial screen.
The difference, however, is about three seconds on an IPC.

I like the menubar.  I like the input model even more.  I have not tried the
dialog boxes yet. :)
-- 
Brian Walker              Software Technology Research Lab, Tektronix, Inc. 
Brian.R.Walker@tek.com    PO Box 500, MS 50-662, Beaverton, OR  97077