On Tue, 21 Jan 2003, Fabio Alemagna wrote: [...] > > You miss, that in X, you never talk to the graphics HW directly. X will > > send you an event when you iconify, and will nicely gobble up all > > your funny drawing requests if you don't act on it. > > Not completely true: if backing store is active the rendering will still > happen on a backbuffer.
Yes. But with X, you must go through X for all graphic operations you do; so the X server can easily manage that feature. For example, X may delay updating the backbuffer until it is needed. [...] > Yes it would. The world is full of examples where it works. Even in AROS > it works, so I don't see why it shouldn't work in KGI. Even if I fully agree with Andreas (and probably most of the computer graphics community) on the technical viewpoint wrt to automatic backbuffer-ring of applications; I do think too (like you) that such a feature should be available. Why? Because there are many people that expect it. Whether I think they are wrong in this expectation is not relevant if it makes more people happy/interesting with/in GGI/KGI. However, due to the difficulty of doing this correctly at the kernel level (because of all the things Andreas outlined: userspace/kernel synchronization, graphic context preservation, VRAM protection and "swapping"), I really think such a behavior should be provided by libggi. At the libggi level, we are pretty near from the X level, the library controls most of the accesses to the framebuffer or accel and certainly can handle a signal itself; so it could provide for most applications a good backbuffer. (It may imply to prohibit access to the DirectBuffer if such backbuffering is done, but most the time, only simple apps want to have a permanent backbuffer.) Rodolphe
