[cairo] API Shakeup: cairo_<device>_surface_mark_dirty

[Mike Emmel]

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 ?

Mike


On 7/29/05, Owen Taylor <otaylor at redhat.com> wrote:
> On Tue, 2005-02-22 at 17:35 -0500, Carl Worth wrote:
> > It has been noted that the current software fallbacks in cairo are
> > obsessively correct (and consequently, horrifically slow).
> >
> > The issue is that the current fallbacks are paranoid and assume
> > nothing about what happens to surface contents between cairo drawing
> > operations. In the off chance that some means external to cairo has
> > been used to draw to the surface, cairo does a fetch, draw, store
> > cycle with every fallback operation.
> >
> > In order to fix this, we propose that the user bear the burden of
> > informing cairo whenever a surface has been modified through external
> > means. The following function is proposed:
> >
> >       void
> >       cairo_<device>_surface_mark_dirty (cairo_surface_t *surface,
> >                                          int x, int y,
> >                                          int width, int height);
> >
> > This is a device-specific backend function, as device-specific means
> > must be used to draw externally to the surface, and some devices
> > (eg. PDF surfaces) do not support external drawing. So, the function
> > should appear for image surfaces, and all display device surfaces. So,
> > that gives us the following new functions as of today:
> 
> Here's an initial implementation of the
> cairo_surface_mark_dirty() and cairo_surface_flush(). The only use
> made of these functions currently is that cairo_surface_flush() for the
> win32 backend restores the clip for the surface's DC to its original
> value.
> 
> Notes:
> 
>  - I made the functions virtual functions that does nothing if nothing
>    is needed. I don't see the point in duplicating it out.
> 
>  - I have separate cairo_surface_mark_dirty() and
>    cairo_surface_mark_rectangle_dirty() functions since I think not
>    knowing the bounds of the dirty region will be common. Internally
>    I use negative width/height to flag this case, but I thought that
>    was ugly to expose in the public API.
> 
>  - I did not make finishing drawing to a cairo_t automatically flush
>    the surface. My thought here is that with GTK+, it's very common
>    to cairo_create()/<draw>/cairo_destroy() many times on the same
>    surface and flushing automatically would destroy much of the
>    efficiency gain for something like the no-RENDER Xlib backend.
> 
>  - I did make cairo_surface_finish() automatically flush, since it
>    seems always desirable. I wasn't sure about error handling;
>    cairo_surface_finish() always calls finish, even if surface->status
>    is set, so I made it also always call flush(), on the theory
>    that a surface might leak if it was expecting to be flushed at
>    finish time but wasn't.
> 
>    (But the win32 surface would *still* leak since it's flush calls
>    _cairo_surface_reset_clip_region() which is a no-op on a finished
>    surface. So maybe we just need to have surfaces assume that they
>    might not be flushed and free all resources in finish.)
> 
> Regards,
>                                                 Owen
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> 
> iD8DBQBC6rz3S+2LB0B90LERApKbAKDHoXimav9KV33l0vuyms97+BH8jQCgxqWR
> nROmivASp64FM5/JMDK/XxA=
> =DoZt
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.freedesktop.org/mailman/listinfo/cairo
> 
> 
> 
>