On Tue, 21 Jan 2003, Christoph Egger wrote: > > On Tue, 21 Jan 2003, Christoph Egger wrote: > > > How about using the memory target within libggi's kgi-target, when the > > > application runs in background? > > > > That's basically what I mean. > > Then you were not precisely enough. By using the word "offscreen", every- > body thought, you mean an offscreen area of the onboard framebuffer...
Why not? If there's enough space in the gfx board memory then the offscreen buffer should be allocated there. > > hw-sprites, I guess, would still be accessed trough an API, right? Hence > > when the visual is not visible just update the internal sprites' state, > > don't actually display them. The same goes for the YUV overlay: redirect > > it to a memory target. When the visual become visible again then refresh > > the display with the content of the various buffers and the sprites. > > That sounds a good idea. But then a) the memory-target must be extended > to "support" overlay resources Not a big deal, is it? Ideally a memory target shouldn't care at all about what it contains, it's just a framebuffer after all. > and b) the GGI application should be notified > somehow, so that the GGI app can stop wasting CPU time with decoding > a video, for example, when it knows that the result (the decoded video) > gets no longer displayed... If there's any support for applications to get notified when they get "iconified", then the kgi case should be aliased to it, that is for the application it's actually the same thing. If there's no such support, then it's time to implement it :) Fabio Alemagna
