Ville Syrjälä wrote:
On Tue, Jan 02, 2007 at 11:12:47PM +0000, Phil Endecott wrote:
Are the surfaces' Color, DrawingFlags, BlittingFlags etc. private to
the surface? Do I need to Lock() before changing them?
Each IDirectFBSurface keeps a private graphics state. So when you change
the colors, flags etc. on one it won't affect other surfaces.
My concern here was that eventually DirectFB has to put these values
into registers in the graphics hardware in order to do the blit, and at
that point you can't have more than one thread trying to do it
simultaneously. Maybe the kernel provides all the locking that is
needed to make this safe - or maybe DirectFB does it, or maybe I have to.
Do I need to lock around calls to the shared DirectFB object, e.g. to
CreateImageProvider, CreateSurface, and so on?
AFAICS using IDirectFB from multiple threads should be OK in most cases.
I was thinking of cases like creating a new surface where DirectFB
needs to allocate memory, which inevitably requires some shared state
[the "free list"] that must be protected. (I still don't really
understand where the memory for surfaces actually is - is this a finite
pool of video ram, or does it come from main memory?)
Thanks for everyone's feedback. As I'm sure you can imagine, only
finding most of the places that need locking only means that the app
will run for a bit longer before crashing; I really need to find them
all. On the other hand, adding too much locking will slow it down.
Cheers,
Phil.
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
