Ilyes Gouta 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 );
}
Yes, that is a problem.
Normally dfb_surface_unref causes the surface to be deallocated and
freed synchronously, so your data->surface pointer is invalid.
Only allowed when you are sure you still have a reference count > 0!
Is it about lazy allocation/deallocation? Who is ultimately going to
collect all the freed chunks from the surface pool?
I admit the path is difficult to follow, but the allocations are freed
directly.
Regards,
Ilyes Gouta.
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
