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? > 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. Not unlocking a surface might result in less performance and maybe a warning during destruction of the surface. -- 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
