Quoting Ville Syrj?l? ([EMAIL PROTECTED]): > On Wed, Jul 10, 2002 at 07:47:50PM +0200, Denis Oliver Kropp wrote: > > Quoting Mike Pieper ([EMAIL PROTECTED]): > > > Hi, > > > > > > this patch (v4l_lockright.patch) has to be applied on my last patch > > > (v4lgrab.patch). It solves problems due to locking the destination surface of > > > the PlayTo function. > > > All locking/unlocking is done in an extra function now. The unlocking at > > > various places in the code is avoided. The back _and_ the front buffer is > > > locked. > > > > In grabbing mode the surface should only be locked while writing the data > > into the back buffer (front buffer should not be locked). Otherwise a flip > > on the surface would hang until the video is stopped. > > > > In DMA mode the surface should not be locked but only have the lock > > counter increased. > > I just looked in how the libmpeg3 provider does the locking and I'd like > some clarification on what the v4l provider should do. > > Should destination->AddRef() be called? I noticed the libmpeg3 provider > uses this.
AddRef() should be called whenever the interface pointer is copied without knowledge of it's creator. So if you are writing an application you know when to Release() it and when it's safe to simply copy the pointer without AddRef()ing. > What about the dfb_surfacemanager_assure_system() call? libmpeg3 doesn't > call this. If you use the dfb_surface_*_lock() functions you don't have to care about that function, because it's called by the locking functions. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
