Tuomo Valkonen (el 2008-05-23 a les 09:17:46 +0000) va dir:: > 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.
Umm, I was curious about what the real memory consumption would be. For instance, let's imagine having no less than 30 windows taking a full 1024x768, 32-bit screen (a *really* bad case, I currently have 12 windows, only three of them near-fullscreen: 30 * 1024 * 768 * 4 = 90 Mib, 150 MiB for 1280x1024. That's not so much by today's standards, given graphics memory size, main memory size and intelligent memory swapping techniques. It may not be right for a small system, but I think it's OK for a desktop system, if the user makes the decision to go into compositing. Regarding your question, I don't know the answer either, but maybe some kind of LRU strategy could be used for selecting which windows have the backbuffer enabled. > 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. Nice, that slightly reminds me of the architecture of the NeWS window system, which used PostScript as that drawing language (a very interesting system and an also interesting read): http://en.wikipedia.org/wiki/NeWS Cheers, :: Ivan Vilata i Balaguer @ Welcome to the European Banana Republic! @ http://www.selidor.net/ @ http://www.nosoftwarepatents.com/ @
signature.asc
Description: Digital signature
