On 2008-05-23, Ivan Vilata i Balaguer <[EMAIL PROTECTED]> wrote: > +1 on my side, too. It turns out that Ion lets me switch windows so > fast I have to wait for them to redraw! A compositing manager could > take all that flickering away.
.. by turning it all slow by constant swapping. Seriously, all apps initially drawing into backbuffers is an absurd and unnecessary waste of memory (and natural resources). It may not show when you run a single program with one big window along with a few auxiliary windows, which is most the WIMP interface can really handle. But Ion you typically have dozens of windows open. Now consider all of them having a backbuffer constantly allocated. Is there any way to turn it off (discarding drawing requests as normal) for (invisible) windows, when not needed? I haven't studied the protocols in detail. I do, however, think that in general a proxy program (compositing manager) copying damaged regions is a wasteful naïve/ad hoc approach plagued various problems, such as memory waste and programs needing speedy redraws (requiring lots of communication and multiple context switches between the original program, X, and the compositing manager, unless the program is set to bypass the compositing manager). An approach reminiscent of pixel and vertex shader programs would probably be better. Instead of uploading shaders to a graphics card, you'd upload a transformation program on the X server, in a non-Turing complete language with guaranteed time bounds. (Of course that program might also specify shaders.) You might then also support general drawing programs, being able to just upload widget drawing programs and stuff, instead of sending all the commands over the socket each time, improving performance over slow networks. In any case, if someone wants to write a compositing manager, please go ahead. I don't think I'll ever find the time; I rather spend what time I find on more "fundamental" ideas... that might be improved by a CM. -- Tuomo
