[cairo] API Shakeup: cairo_<device>_surface_mark_dirty

[Owen Taylor]

On Sat, 2005-07-30 at 09:35 -0400, Mike Emmel wrote:
> On 7/30/05, Owen Taylor <otaylor at redhat.com> wrote:
> > On Fri, 2005-07-29 at 20:21 -0400, Mike Emmel wrote:
> > > Good this should also handle the problematic case of a native surface
> > > format unsupported by cairo. I create a supported secondary format
> > > internally for the directfb backend.  In general should the backend
> > > specific create function do this or fail with a unsupported format
> > > error ?
> > 
> > I don't understand the relationship. These functions are for an
> > application to use when mixing (say) X drawing with cairo drawing.
> > 
> > Regards,
> >                                                 Owen
> > 
> 
> Using a intermediate buffer was also very slow without this.
> 
> Technically if your using a intermediate buffer because the target
> surface is not supported by cairo you should ask cairo to blit its
> buffers before marking a region dirty.

I don't see how cairo_flush() helps here. I thought about making
cairo_flush() have return or out parameters indicating:

 - Whether anything was flushed
 - Flushed area

But cairo can go ahead and draw at any time, that wouldn't really help.
If you want to make using a shadow buffer efficient, you'd need
something like the "Damage" X extension hooked up to a surface.

> So its slightly different case. Which brought up my question.  If the
> target surface is not supported by cairo but you can create a internal
> buffer that is supported should the backend do this ? Cairo supports a
> very limited number of surface formats so dealing with a source format
> not supported by cairo is prob common.
> YUV,16 bit etc etc.

[cairo can draw fine on a 16bpp local buffer; there's just no support
for it in the public API.]

I don't know what you mean by backend here, which I think is inhibiiting
my ability to understand the rest of the question. Are you talking about
writing your own cairo backend inside cairo?

							Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050730/9a13f63e/attachment.pgp