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? 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). 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. -- Ian. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
