My general feelings towards the prospect of keeping tasks drawing in the background, whether on memvisuals or in VRAM, is that it would be a very nice feature but it would also be an incredibly hard and time consuming thing to implement.
The challenges, most already noted by others in this thread are thus: 1) Falling back to sw renderers is nontrivial when lots of extensions are in use. 2) Using hw renderers on VRAM requires that the hw graphics context match the mode. This would require KGI to be integrated into the process scheduler and restore the GC on process switch, not just on VC switch. Sometimes it can even require that the CRTC mode matches on some chipsets and in those cases it will be just plain impossible when the focused application is using a different mode than the background one. 3) Using VRAM requires that KGI isolate one application's area of VRAM from another's and keep them from reading or writing into each other's data. It also requires centralized resource allocation. 4) As mentioned before, using RAM to preserve the whole FB state can get very expensive in some situations. Of the above, if I was to pick one to work on it would be #3 because there are a number of less difficult partial solutions that could be implemented in this area and have some neat benefits: There are various reasons why we might want to make KGI capable of restricting applications to accessing only a portion of the VRAM. Foremost among them is multi-headed cards with shared framebuffers running processes owned by different users (unfortunately this brings us back to the GC problem in #2 unless we restrict the modes available on one head based on what's being run on the other). Another, relatively easy perk might be to convince KGI to support apps running in the background while displaying a textmode VC on the focus. Finally, limiting the area of VRAM corrupted during VC switching may save applications from redrawing all but a small part of their screen, and reduce the size of any RAM buffers used to store backup data, if #4 were ever implemented. All in all though I don't think any of the KGI core folks can afford to be distracted by these issues, and a one-drawing-process-per-card model will be the soup of the day. Maybe later when we have a stable and secure KGI out the door we can start to work on them. -- Brian
