On 7/18/05, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
> Quoting Mike Emmel:
> > I think I understand some of the bugs I'm seeing with locking. It
> > seems that its common to create a surface lock it do something then
> > release it.
> 
> Oh, the gdk code doesn't unlock the surface before releasing it?
> 
Acutally it does my first reading was that it was not unlocking.

> > Which is fine if the surface is destroyed if not then the
> > surface remains and is locked.
> 
> To implement a GdkImage the surface needs to be locked all the time,
> because the application expects the data pointer to be always valid.
> 
> All other use cases of a surface should only lock the surface as
> long as it's really required, i.e. while writing with the CPU to them.
> 
> > Should Release Unlock the surface I
> > think not but I just wanted a opinion. I also made the mistake that
> > Release would unlock till I looked at the code.
> 
> Releasing a surface should unlock it, but indeed the destructor
> of IDirectFBSurface doesn't do that. It's not critical, but it
> should be added though.
> 
It might in some cases  I'm a bit concerned about subsurfaces  not
unlocking correctly. In anycase it probably should to be safe.

> Not unlocking a surface might result in less performance and maybe
> a warning during destruction of the surface.
> 

What I'm getting in the debugger is the Surface Lock/Unlock pair seems
to be done correctly for images and with cairo which does direct
access but for using the directfb rendering api's you need the surface
unlocked but It seems to reach draw_rectangle locked event though it
was unlocked by cairo correctlly in pairs from the debugger.  I'm also
looking at the lower level dfb_surface_lock/unlock unlock is called
way more then lock but agian I don't see that the lock is held before
the drawing.

All I can guess is that the surface may have been free'd and I'm
seeing a garbage value in the lock..

Mike

> --
> Best regards,
>   Denis Oliver Kropp
> 
> .------------------------------------------.
> | DirectFB - Hardware accelerated graphics |
> | http://www.directfb.org/                 |
> "------------------------------------------"
>

_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev

Reply via email to