Re: GDK-DirectFB Patches
- From: Denis Oliver Kropp <dok directfb org>
- To: Carl Worth <cworth cworth org>
- Cc: gtk-devel-list gnome org, Claudio Ciccani <klan users sf net>, directfb-dev directfb org
- Subject: Re: GDK-DirectFB Patches
- Date: Thu, 06 Dec 2007 21:49:54 +0100
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.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]