Re: GDK-DirectFB Patches

[Denis Oliver Kropp <dok directfb org>]

Denis Oliver Kropp wrote:
> Carl Worth wrote:
>> On Thu, 06 Dec 2007 09:44:55 +0100, Denis Oliver Kropp wrote:
>>> Carl Worth wrote:
>>>> For interleaving cairo and non-cairo rendering, cairo provides the
>>>> cairo_surface_flush and cairo_surface_mark_dirty APIs. Does
>>>> cairo-directfb implement those and does your application use them.
>>> Thanks for the pointer. The cairo-directfb backend seems to do nothing
>>> in these functions. I'm not sure what it's supposed to do. Should the
>>> first accumulate a region to flip and the second actually flips?
>> I don't know how cairo-directfb surface is implemented exactly. So
>> I'll describe the general concepts and then illustrate them by way of
>> a fictitious "shadow" backend that is implemented with a
>> cairo-image-surface internally and can copy back and forth between
>> that and some underlying "system" object.
>>
>> When an application wants to switch from cairo- to non-cairo-based
>> drawing it should call cairo_surface_flush. In this case, our shadow
>> backend would copy its state from the image surface to the underlying
>> system. (Ideally it would copy a minimal region based on the extents
>> of cairo drawing operations that have occurred, but cairo's current
>> backend interfaces don't make it easy to know this. But there would be
>> no API impact from improving that.)
>>
>> Then, when an application wants to switch back from non-cairo- to
>> cairo-based drawing it should call cairo_surface_mark_dirty_rectangle
>> one or more times. Our shadow backend would accumulate a region from
>> these rectangles and before the next cairo drawing operation would
>> copy that region from the system to the image surface.
>>
>> Does that make sense?
> 
> Yes. Thanks for your explanation.
> 
> The cairo-directfb surface uses the "system" object directly, which is an
> IDirectFBSurface. For each source/dest acquire it does a Lock() to get the
> surface data pointer and pitch and calls cairo_image_surface_create_for_data()
> which is not too heavy for every acquire I hope.
> 
> So flushing and marking is not required.
> 

I'd also like to see that revived:

 * @CAIRO_FORMAT_RGB16_565: This format value is deprecated. It has
 *   never been properly implemented in cairo and should not be used
 *   by applications. (since 1.2)

Embedded devices running at 16bit should be able to use Cairo without
converting back and forth.

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"