Hi,
I have a small test application that used to determine how much VIDEO RAM that
is available for DirectFB since some drivers fail to report the correct size.
This application essentially tries to allocate as many surfaces (10-40k size)
as possible until we run out of memory.
This has worked fine on DirectFB 1.0 but after upgrading to 1.4.3 this does not
work any more.
I have tested this on one embedded device with HW acceleration and it just
keeps creating surfaces far above the GFX heap limit and eventually crashes.
Running the same application on x86 without HW acceleration shows similar
behaviour. Since there are no VIDEO_RAM available to DirectFB I would expect
the IDirectFB::CreateSurface function to fail with an error, that's what
happened in DirectFB 1.0 at least.
*code*
DFBSurfaceDescription dsc;
dsc.flags = DSDESC_WIDTH | DSDESC_HEIGHT | DSDESC_PIXELFORMAT | DSDESC_CAPS;
dsc.width = WIDTH;
dsc.height = HEIGHT;
dsc.pixelformat = pixelformat;
dsc.caps = DSCAPS_VIDEOONLY;
vram_size = 0;
while (true)
{
err = dfb->CreateSurface( dfb, &dsc, &dest );
if (err != DFB_OK)
break;
vram_size += pitch*HEIGHT;
}
print_result(vram_size);
*end code*
I read here in the forum that DirectFB doesn't allocate the surface buffer
until a graphics operation is actually performed on the surface. I have tried
to add a FillRectangle call in the loop but no success. Also specifying
DSCAPS_STATIC_ALLOC for the surface gives no improvement.
So what have changed between the tested versions and what does a solution looks
like that works across DirectFB versions?
Best regards,
Karl
_________________________________________________________________
Mejla på krogen! Hotmail i mobilen.
http://new.windowslivemobile.msn.com/SE-SE/windows-live-hotmail/default.aspx_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
