[Cairo] Cairo on older X servers, (eg. with Render version 0.2)

[Bill Spitzak]

On Friday 10 October 2003 07:00 am, Carl Worth wrote:

> And as for speed, I've done the experiment and it doesn't look hard to
> get rid of all the XGetImage traffic and most of the XPutImage traffic
> that currently happens when rendering to an old server.
>
> The trick to being able to do this is to add a few new functions which
> allow the user to give Cairo the information it needs:
>
> 	/* Clear the current target surface (to solid white). */
> 	void
> 	cairo_erase (cairo_t *cr);

I think it would be better to have all drawing operations be restricted to 
the clip region. However "fill the clip region with solid color" is a pretty 
useful operation and cairo should have it. And internally it can detect that 
there is no clip region and thus do what you intend this call to do.

> 	/* Guarantee that the results of all previous painting
> 	   commands have been applied to the surface. */
> 	void
> 	cairo_flush (cairo_t *cr);

Probably a good idea. This call can also be used to print a page in a cairo 
printer interface.

Will this do an XFlush? My thinking right now is that is unnecessary, but I 
can see arguments both ways.

> 	/* Must be called whenever the current surface has been
> 	   drawn to by something other than cairo. */
> 	void
> 	cairo_mark_dirty (cairo_t *cr);

It is possible this should be in the device-specific interface.

First, you may want to pass device-specific arguments, for instance a 
rectangle or X region would be very useful for reducing the amount of data 
read from the server.

Second, you may want to avoid having to implement this for every device. I'm 
pretty certain any OS will provide some other way than cairo to draw on 
things and thus in theory this should work for them. But it would be a real 
pain to, for instance, read back the current image from a Postscript printer. 
If you say "this only works for X windows", why not put it in the X-specific 
area?

Third: be warned that this is not going to work as well as expected: Reading 
the pixmap back will read back parts of overlapping windows, so the image is 
not correct, the result is that the application is required to redraw *all* 
cairo graphics that are in the dirty region, it cannot do incremental update. 
You may think it can assume that the visible area is correct, but overlapping 
windows may have moved between when it received the expose event and when the 
region is read. You may think this means you have to respond to all expose 
events, but in fact save-under will mess this up, as will servers that try to 
optimize away exposes that they think are unneeded because the app changed 
all the pixels in the exposed region. Thus it may be a good idea to 
discourage use of this.

-- 
                   ,~,~,~,~ ~ ~ ~ ~
     /\_       _|_========___         Bill Spitzak
 ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com