I just start now in this heated discussion. Apparently, there are several subjects: 1) Whether generic backbuffering is desirable or not in general; 2) Whether it is possible to implement such a backbuffering mechanisms in a safe way on current hardware.
As to 1), I guess this is primarily an application point of view. It seems to me that applications that are worth a backbuffer are those that do not have an easy mean to redraw their screen entirely. These are probably: fastly written small apps, and apps that do a lot of computations to produce the pixels (raytracer for example). Other applications (GUI, games) apparently have enough internal information to recompute a display. Furthermore, these applications will probably want to stop doing CPU expensive drawing while they are not visible. Concerning 2), I'd say that from the KGI perspective, it seems to me that such a backbuffer system should, if possible, be managed by a userspace library. It seems to me that it is much safer if userspace takes care of moving/saving fb-related memory. This is simply because there is usually no MMU-like features (page tables, memory protection) wrt the graphic board memory; so nearly none of the VM mechanisms used for main memory are applicable. Of course, KGI could provide a systematic save of fb memory into main memory on context switch, but, as many of you outlined already, given the trend in memory size on graphic boards, this is probably not realistic. Plus, it seems to me that, if LibGGI imposes a few restrictions on the application that wants a backbuffer (like, the interdiction to use DirectBuffer), it can be done pretty easily, and probably transparently to the application. (I noted that it may not be so easy to replace the functions of one display with those of the memory display, but can't these problems be solve?) A possible impact of this discussion is the fact that, from the KGI point of view, we should really take care to identify the resources that are preserved transparently accross a VT-switch and those that are not. (Pointer position comes to my mind for example, in the future, AGP-capable memory, or in-main-memory graphic buffers.) Well, in fact, from the KGI perspective, I'd like to say that I am extremely reluctant to make provision to send all of VRAM to swap on VT-switch. In fact, I would be more favorable to use some of the VRAM as a swap area... :-) Rodolphe
