On Tue, 21 Jan 2003, Fabio Alemagna wrote: > uh? Because it's not the same thing and because it's NOT TRANSPARENT! The > whole point of kgi/ggi is that the app doesn't _know_ where it's running, > so tying it with a specific target is the dumbest thing to do.
> look there: "vtswitch_request". So, does any ggi app have to implement > that? Or will there be some ggi apps that run on kgi and other that don't? > The app _doesn't_ have to care about where it runs, I should be able to > run it on X and on KGI without having to touch one line of code. Your > approach defeats the whole point of ggi. Any GGI app which does not implement a response to the GII "expose" event runs the risk of having it's screen corrupted. This is not a display-dependent problem, and can happen on display-svgalib and display-fbdev already. If the GGI app were running on, say, display-x:-nobuffer or the old display-xlib, then even if the server had backing store turned on (by default, X ships out of the box with backing store disabled on most distributions) then there is *still* the chance that backing store will run out and the server will send an expose event to get the application to redraw. It is quite clearly indicated in the X server documentation that backing store is not guaranteed. The new display-X does implement a backbuffer, but this is for performance reasons, not to provide applications with a false sense of security. If you want an application to have a RAM back-buffer, you should run it on (or code it to explicitly request) display-tile and use your desired target as a slave tile visual. This will hurt your performance, but it will give the application the "transparent" feel you want. (Note: display-tile needs to have work done to make it's backbuffer handling as efficient as display-X. Both displays could use a more sophisticated dirty-region management helper sublib.) -- Brian
