Shaun wrote:anyway, is it better for puting redrawing work in user apps?
This depends not on what's "better" but what method you use for drawing windows.
The traditional method for drawing windows is that each application gets its turn to draw directly to the screen, usually through some sort of "pen". This means the only source of truth for what a window looks like is the pixels on screen, and the applications themselves. So if we move a window, all of the applications underneath it need to redraw (the window we moved doesn't necessarily need to redraw though, as we can bitblit it from its old position to its new position if it was the top window). The primary advantage of this system is that it is very inexpensive for memory - you only have the display memory to worry about, and you're probably not even double buffering it. The primary disadvantage of this approach is it is time expensive to redraw things, which you're going to be doing a lot of, and a misbehaving application will cause graphical issues for the whole system.
Modern OSes have moved away from this approach to what's called
compositing window managers or
compositors. Compositors work by giving each individual window its own buffer (or canvas), which the application is free to draw into in some way: sometimes by pens (old Windows apps, X11 before the SHM extension), but more often through direct access - perhaps through a 3d graphics interface (Direct3D, OpenGL). When a window moves or changes, the screen is redrawn (with appropriate optimizations) from the various window buffers by the compositor (often employing effects like alpha blending). Through this approach, an application will never have to service a redraw request - it doesn't even need to know about changes to other applications' windows. We can also perform additional effects like
rotating windows or even
mapping windows to surfaces in a 3d environment.
Windows has used a compositor (
DWM) since Vista. OS X has used a compositor (WindowServer / Quartz Compositor) since its first release (originally purely in software, then later hardware accelerated). X11 has had a number of compositors, notably Compiz (which I worked on), and all of the modern DE window managers (KWin, Gnome's Metacity and Mutter, etc.; Ubuntu' Unity is just a plugin for Compiz). Wayland is seeking to replace X11 and is effectively a compositor protocol, with no room for the traditional approach.
While compositing window managers have quite a bit of history (the Amiga had a compositor), they were not popularly used until OS X, primarily because holding a buffer for each individual window takes a lot of memory. With modern graphics cards, and even just modern RAM, this isn't an issue any more, so modern systems are overwhelming using compositing.
