Talk:Stacking window manager
 | Computing: Software C‑class Low‑importance | ||||||||||||
| |||||||||||||
Who says stacking window managers have to use painter's algorithm?
This:
Stacking is a very slow process, requiring the redrawing of every window one-by-one, from the rear-most and outer-most to the front most and inner-most. Many stacking window managers don't always redraw background windows. Others can detect when a redraw of all windows is required, as some applications request stacking when their output has changed.
contradicts this:
A stacking window manager is a window manager that draws all windows in a specific order, allowing them to overlap, using a technique called painter's algorithm.
99.224.115.100 (talk) 20:40, 22 October 2009 (UTC)
"Microsoft Windows XP still exclusively uses a stacking window manager, which has presented severe limitations to its ability to display hardware-accelerated content inside normal windows,"
There is no source of information for this content. What are these "severe limitations"? I have seen accelerated content running just fine inside normal windows on Microsoft Windows XP.
Markhobley (talk) 11:33, 22 July 2010 (UTC)
It seems to me like the article is very biased against its own subject. Perhaps it could be rewritten in part?
71.220.222.208 (talk) 02:10, 14 August 2010 (UTC)
Also, this article touts Windows as an example of a stacking WM, but the description of what a stacking WM is looks nothing like what Windows actually does. I don't think a partial rewrite will fix this article, it needs to be rewritten completely, which is why I will blank it. —Preceding unsigned comment added by 82.139.87.74 (talk) 01:31, 20 August 2010 (UTC)
Oh well, apparently you can't even blank an article if blanking would be a considerable improvement. Wikipedia sucks. —Preceding unsigned comment added by 82.139.87.74 (talk) 01:35, 20 August 2010 (UTC)
Bullshit
Quote: Stacking window managers allow windows to overlap by drawing them one at a time. Stacking, or repainting (in reference to painter's algorithm) refers to the rendering of each window as an image, painted directly over the desktop, and over any other windows that might already have been drawn, effectively erasing the areas that are covered. The process usually starts with the desktop, and proceeds by drawing each window and any child windows from back to front, until finally the foreground window is drawn.
- Neither Atari GEMDOS nor Win 3.11 nor XWindows work this way!!! They all use clipping regions, so unless the programs purposely turn off clipping, they cannot draw outside the window. Thus it is completely irrelevant in which order the windows are drawn. -- Sloyment (talk) 19:57, 3 October 2011 (UTC)
No sensible window system has ever used the painter's algorithm
The article is simply wrong. I don't know of any (non-toy) window system which uses the back-to-front 'painter's algorithm' as its default strategy. The usual approach involves keeping track of clipping 'regions', usually as sets of rectangles, and working front-to-back. In order to redraw a given 'damaged' region of the screen, you start with the frontmost window, intersect it with the damaged region, and repaint the intersection; then you subtract the window from the damaged region and, if there's any left, continue with the window behind. (A window system which has a window hierarchy obviously applies this algorithm recursively to repaint each window.)
Clearly, a window system which repainted back-to-front would either suffer horrible flicker as it repainted a window, or have to implement double-buffering, so following some damage the system would appear to freeze while the damaged area was repainted, and then there'd be an instantaneous update. I've never seen either behaviour.
Some caveats: I know that Acorn's RISC OS window system uses the front-to-back technique I've just described, but it has a limited amount of memory for keeping track of the damaged region: if it becomes too complicated, it gives up, clears the screen, and really does redraw back-to-front using painter's. I'm not sure what percentage of users ever saw this behaviour, but it won't be large: I remember testing for a while to provoke it.
I'd rewrite the article, but I don't know anywhere this stuff is actually written down readably. I could provide references to pieces of the X source code, I suppose, but that doesn't help with my assertion that everybody does it this way.