> > > Why not? If there's enough space in the gfx board memory then the > > > offscreen buffer should be allocated there. > > And not be available for another application I start on the switched to > > console? > Why not? Just make the bg app go back to use its own offscreen buffer
That requires _cooperation_ of the bg app. If the bg app cooperates, this is all a non-issue. See my proposal on handling it. Handling it _outside_ the application is what I am opposing. > Maybe I haven't explained myself very well: ONE offscreen buffer PER > independent visible buffer, which means that the overlay would go in a > buffer of its own, the sprites would just not be rendered at all and the > standard display would get a buffer of its own as well. Pretty much complicated and almost never needed. See my other posting. Where would overlays and sprites make sense? I see two main areas: 1. Video decoding into an overlay. This might use graphics card features anyway. I may just be sending MPEG Data right to a grphics card port. To go to backbuffer, much more has to be done than just redirecting some memory areas. Moreover video decoding makes no sense while switched away, so better stop the app completely. And if it looses its FB content: So what. It is producing new frames at about 25/sec. Just let it redraw. 2. Games. Again they will want to use a high framerate and can just redraw. > > Yes there is such a mechanism for X. But it is totally X-specific and > > cannot be generalized. > If it _can't_, then I'm afraid the implementation sucks quite a bit 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. When you deiconify it will tell the app and ask to redraw. > then (no offence intended): the application doesn't have to care of > whether it's in X or not, it just has to care of whether it's still > visible or not. Seems like we are not talking about the same thing. What I advocate is: 1. Tell the app, if it looses visibility. 2. Let the app decide what to do. Doing that behind its back won't work out. See my other posts on that. CU, Andy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
