[cairo] API Shakeup: cairo_<device>_surface_mark_dirty

[Mike Emmel]

First I've written a cairo backend for directfb sorry for the confusion.

On 7/30/05, Owen Taylor <otaylor at redhat.com> wrote:
> 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.
> 

Assuming Cairo does a good job of sending reasonable intrest rects when it
does a good job in  _cairo_surface_release_dest_image I can track the
damaged areas. I just need a flush before external writes. The cairo
drawing needs to go underneath the external draw code. So  to draw
using cairo and some other method you need aquire/release api IMHO.

> > 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 know I really think it should be exposed before you go 1.0 its a
very common surface format. Next would be some YUV support but thats
not as critical.
I'd turn it on if someone is willing to apply the patch.

> 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?
> 
Yep.

So agian should the cairo backend create a shadow buffer to hide
formats that cairo does not support or should it fail and if so we
need and api to get supported formats.  I can see the need for
secondary shadow buffers in a number of cases.

>                                                         Owen
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> 
> iD8DBQBC64tZS+2LB0B90LERAgbYAJ9TWs9HrSgUxURTwirTYQFcruNpCgCdEUo+
> s0Q0T6mgghWWNxWWTkq8CI4=
> =/C7w
> -----END PGP SIGNATURE-----
> 
> 
>