Quoting Ian Walters: > On Friday 09 January 2004 12:37 pm, Ville Syrj�l� wrote: > > On Thu, Jan 08, 2004 at 10:09:09PM +0100, micronuke wrote: > > > Hello, > > > > > > is it possible to create an IDirectFBWindow without a surface? Or create > > > a window with a surface, then at some point take its surface away and > > > later attach a surface to it? > > > > > > This may sound strange.. thus I'll explain. Every DirectFB-window has a > > > surface attached to it.. When you have many windows, this can easily need > > > a lot of memory. If I have a window that doesn't have focus and doesn't > > > need to be updated until it gets focus again I could blit it onto the > > > primary surface, remove its surface (and thus free the memory) and later > > > when a focus event arrives recreate and redraw the surface (if I remove > > > the complete IDirectFBWindow there won't be any more focus events ;). > > > > You need the surface for window stack updates. DirectFB doesn't have > > expose events like X. > > If you have a lot of windows your screen is cluttered anyway :) Although the > comment does lead me to wonder, if I have a small window, does it still use > memory for the entire size of the screen, or is there an clipping->null > optimisation to save memory (possible at the cost of speed?) And if this is > done, then is is possible some layers that are partially covered and not > updating will have a chance to page out of memory?
Of course, each window only consumes memory for its own size. The surface manager will swap out "hidden" windows if the video memory is full. The system memory instance will be swapped out by the kernel. While the kernel swaps out page wise, DirectFB only swaps out complete surfaces. > Then it wouldn't matter that you had 20 windows open since each would only use > up enough memory to display its own contents anyway. This would be a better > optimisation than trying to have all the windows on one surface. It would be > very hard to generically ask apps if they may update graphics in the next 20 > seconds. Determining if an app may need to update graphics sounds similar to > the halting problem, (so you might as well use your own windows on that > layer and pull expose event codes from a more traditional implementation). Especially with alpha blended windows the clipping approach (traditional) is not applicable. > Also this sounds more like a user problem. If I have 20 windows open and my > machine starts running out of memory I have 3 options > > a) buy more memory > b) close some windows > c) turn window oppacity 100%. Sooner or later the lower windows will be > swapped out if the apps are not updating graphics and the DFB doesn't need to > read them (assuming large areas of the screen is 100% accounted for before it > gets to that layer). > d) accept that 20x2048x1024x4 (20 windows, resolution, bytes per pixel?, I am > guessing) is still only 160meg, and some video cards have more memory than > that these days. > > Still, an interesting thread.... look forward to seeing how it turns out. True ;) -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
