3 ms·
> X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows. I wonder how the comparis
by eadmund 9y ago
> X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows.
I wonder how the comparison between X11 & NeWS works once when switches to tiling window managers, which require much less work & chrome from the WM.
If tiling WMs favour the X model, I wonder if the real reason so many of us like them is that they are faster, rather than tiling being a better paradigm. I suspect that's not the case — at this point, tiling really feels better to me — but maybe it is?
- DonHopkins 9y agoI think the benefits of extensibility far outweigh any differences from whether the window manager supports tiling or overlapping windows. Ideally it should be general purpose enough to support both. Having an extensible window server enables you to use simpler but powerful primitives (X windows -vs- NeWS canvases, or server grabs + XOR RasterOps -vs- overlay canvases and hardware overlay planes), then implement the higher level stuff flexibly in software: see my other message about the complexity of X window borders, backgrounds and shapes, and how it makes shaped windows unbelievably complicated, even though nobody actually ever needs to use that complexity. NeWS canvases don't need special built-in borders, because the PostScript interpreter and stencil-paint graphics model's clipping path elegantly solves the problem that X window borders were trying to solve (but didn't solve well enough for anyone to ever use), and solve many more problems in a much more general way. NeWS had an overlay canvas for non-destructively drawing rubber band feedback over the desktop, which used hardware graphics planes if available, or fell back to using a display list and XOR RaserOps on monochrome or simple 8 bit displays. Some of the popular Sun color framebuffers (cgsix and gx maybe?) had 8 bits of color pixles and a two bits of overlay planes for cursors and black-and-white windows. SunView knew how to use it for the cursor and light weight monochrome windows, and NeWS used it for the overlay plane, which was perfect for window management and rubber band feedback. Drawing the cursor in the overlay plane actually sped up graphics performance a surprising amount, since the drawing code didn't have to always check if the cursor was overlapping where it was about to draw, then hiding and redrawing it before and after drawing anything on the screen under the cursor. NeWS could directly open framebuffers on the overlay plane (1 bit black and white) and overlay enable plane (1 bit that switches between the showing the black and white overlay plane, or showing through to the color framebuffer). Then you could draw on the overlay enable plane to flip between the black and white and color framebuffers on a per-pixel bases (useful for making rubber bands, text labels, 50% checkerboard shadows and highlights, etc). SGI's 4Sight (their own port of NeWS 1.1 that they integrated with X11 and GL, before Sun's X11/NeWS) also supported hardware overlay planes, and used them for the pop-up menus, so it didn't have to repaint the thick 24 bit graphics underneath the thin monochrome menus when they popped down. My NeWS pie menu code "just worked" in the overlay plane with only a little modification, except that I had to special-case the color wheel pie menu to not use the overlay plane, because the overlay planes weren't allowed more than three colors (black, white, one user defined color, and transparent). If you're into the history of window management, here's some fascinating stuff about the evolution of window managers, including Andrew, which is a tiling window manager that Gosling and Rosenthal worked on at CMU before NeWS. It also discusses and compares PERQ PNX, APOLLO, SunWindows, MG-1, Sapphire, BLIT, Smalltalk, DLISP, Interlisp-D, Tajo/Mesa, Cedar Docs and Viewers, Star, Viewpoint, and even SunDew (NeWS). "Methodology of Window Management": http://www.chilton-computing.org.uk/inf/literature/books/wm/overview.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/... By F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986. My favorite chapters: "A Comparison of Some Window Managers" by Tony Williams: http://www.chilton-computing.org.uk/inf/literature/books/wm/p003.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/... "Ten Years of Window Systems - A Retrospective View" by Warren Teitelman: http://www.chilton-computing.org.uk/inf/literature/books/wm/p004.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/... "SunDew - A Distributed and Extensible Window System" by Games Gosling: http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/... "User Interface Working Group Discussions": http://www.chilton-computing.org.uk/inf/literature/books/wm/p017.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/... "User Interface Working Group Final Report": http://www.chilton-computing.org.uk/inf/literature/books/wm/p018.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/... Here is some of the ui working group discussion specifically about tiling windows: 17.2 INTERFACE TECHNIQUES Some of the issues supplied to the Working Group were felt not to be issues at all; as an example, tiled and overlapped windows were seen to be merely options that the user interface designer could use if appropriate. Indeed, a user connected to more than one host, one providing a tiling environment and the other not. might well have both mechanisms to interact with at the same time. Window grouping and subwindows received some attention. A subwindow is not necessarily identical to a window: for example a subwindow receiving input it does not understand refers it to the parent for treatment, and if a parent window is deleted then so are its subwindows. Subwindows in some systems can overlap. while others permit only tiling. Title lines, which can be considered as a form of subwindow. may need to be accessible to the application.