Mike Emmel wrote: > On Dec 5, 2007 10:40 AM, Carl Worth <[EMAIL PROTECTED]> wrote: >> On Wed, 5 Dec 2007 10:22:08 -0800, "Mike Emmel" wrote: >>> And next we need to make sure that we are not breaking gdk. One >>> approach may mean to pass in a features arg >>> when initializing Cairo. It could be a simple bool accel or no >>> acceleration. >> I'm not interested in anything like that at all. If it's not correct, >> then it's not acceleration---it's just broken. >> > > Well not quite. One of the problems is that DirectFB directly supports > a lot of surface formats > not supported by Cairo but it does not have the complex drawing api. > When you dealing with incompatible surface formats and software fallbacks it > tends to be better to just use the fallbacks instead of trying to > interleave accelerated direct calls > and redirected software fallbacks. I've not come up with a general > way to interleave a Cairo context > with directfb calls. So depending on how you do things you can get > unexpected results.
I'm seeing _cairo_directfb_surface_acquire_dest_image() and _cairo_directfb_surface_release_dest_image() which probably get called before and after cairo's software fallbacks. These call Lock() and Unlock() so DirectFB has a chance to synchronize with the accelerator. I don't see a problem with interleaved cairo/directfb drawing, but maybe you're talking about something different. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
