[Cairo] Cairo on older X servers, (eg. with Render version 0.2)
spitzak at d2.com
Fri Oct 10 11:21:36 PDT 2003
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). */
> 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. */
> cairo_flush (cairo_t *cr);
Probably a good idea. This call can also be used to print a page in a cairo
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. */
> 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
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
More information about the cairo