Hi,
Actually my problem is a bit deeper that just that.
I can't find where dfb_surfacemanager_displace() is plugged in the
fbdev system driver, it's not exported as a MockOut pointer like
what's done for the X11 system driver (only through the
vpsmem_surface_pool). This suggests that dfb_surface_pool_displace(),
in DirectFB's core won't be able to call that function to recover
freed allocations. Also that function won't switch to the generic
displace code since allocation from fbdev doesn't get marked with
CSALF_MUCKOUT anywhere!
So, all in all, how does offscreen vram surfaces/allocations get
recycled within fbdev?
Regards,
Ilyes Gouta.
On Mon, May 3, 2010 at 10:55 AM, Ilyes Gouta <ilyes.go...@gmail.com> wrote:
> Hi all,
>
> What's the reason behind not calling dfb_surface_destroy_buffers()
> within IDirectFBSurface_Destruct( IDirectFBSurface *thiz )?
>
> At the epilogue of that function there is:
>
> if (data->surface) {
> if (data->locked)
> dfb_surface_unlock_buffer( data->surface, &data->lock );
>
> dfb_surface_unref( data->surface );
> }
>
> Is there any problem turning that into a:
>
> if (data->surface) {
> if (data->locked)
> dfb_surface_unlock_buffer( data->surface, &data->lock );
>
> dfb_surface_unref( data->surface );
> dfb_surface_destroy_buffers( data->surface );
> }
>
> Is it about lazy allocation/deallocation? Who is ultimately going to
> collect all the freed chunks from the surface pool?
>
> Regards,
> Ilyes Gouta.
>
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
