> > Quoting David C. Jedynak: > > Is there a way to find out how much memory is left in > the videoonly heap > > before setting up a surface in it? I'm pretty tight on > VRAM space, and I > > was wondering if there was a simple way to find out how > much room was > > left, from within runtime code of a directfb > application, so I can protect > > against errors and fail gracefully (like setting a > surface in system > > instead of video, but at a performance penalty) rather > than dying. > > Hi, > > I can add a way to query the amount of free RAM, but it wouldn't be > a definitive answer. Allocation might still fail if the free space is > too fragmented. Defragmentation of free space by moving > surface buffers > around (using hw) has to be implemented in the surface manager which > I'd like to rewrite before adding this feature.
Is it possible to "manually" defragment by releasing all surfaces, and then recreating each? > > Anyways, your application shouldn't die if creation of a video only > surface fails. If you encounter a crash or any other bug in DirectFB > related to failing creation of video only surfaces, please tell us. > I'll keep an eye out for this. I'm going to be squeezing a fair amount of stuff into a 2MB buffer, but it is pretty static (lots of buttons and backgrounds, and some "cache slots" for some fixed size runtime load images), so I don't expect fragmentation. I'm just looking out for stupid bugs on my side for this embedded app, and haven't gotten up the enthusiasm yet for adding up (by hand) the pixel counts of all my cached images to see if they, plus the front and back buffer exceed my video ram space. Thanks for the info, and thanks for DirectFB. I'm having a blast with it, and am looking forward to contributting some code back once my work week drops to a more reasonable 40-50 hours a week and I meet a few deadlines. Back to work, David
