Unger Richard wrote: >> Can anyone offer any advice about the requirements for >> multi-threaded DirectFB applications? >> >> I.e., if two threads both need to access the directfb system >> (to create surfaces, decode JPEGs, blit to the screen etc), >> does directfb do the necessary locking, or must the >> application do this? If it's the application's >> responsibility, what operations cannot be concurrent?
> If accessing the same DFB structures from multiple threads of the same > process, my guess is that you will have to synchronize everything quite > carefully yourself. > One exception should be the DFBSurfaces, and drawing to them. By using the > DFBSurface->Lock() function you should be able to synchronize the actual > drawing operations. Thanks Richard. So if I have two threads, each with their own private surfaces, do they need to call Lock() before writing? Or is Lock() only needed if that particular surface might be accessed by more than one thread? Are the surfaces' Color, DrawingFlags, BlittingFlags etc. private to the surface? Do I need to Lock() before changing them? Do I need to lock around calls to the shared DirectFB object, e.g. to CreateImageProvider, CreateSurface, and so on? (Does directfb do any locking at all for me? Are the DirectFB functions reentrant?) Cheers, Phil. _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
