Re: GDK-DirectFB Patches

[Denis Oliver Kropp <dok directfb org>]

Mike Emmel wrote:
> On Dec 5, 2007 10:40 AM, Carl Worth <cworth cworth org> 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/                 |
"------------------------------------------"