[cairo] Vector screen capture with Cairo

Peter Clifton pcjc2 at cam.ac.uk
Wed Apr 4 19:57:23 PDT 2007


On Wed, 2007-04-04 at 14:07 -0700, Carl Worth wrote:
> Hi Peter,
> 
> I think this is a really interesting thing that you are looking into,
> and I'm looking forward to hearing more from you as you make progress.

I made a little more progress.

The code I've used is crude - very crude. I have an LD_PRELOAD shim,
which creates a .pdf surface on initialisation.

I hook cairo_create, and for every call, I also run cairo_create to get
a new context on the .pdf surface. I store the mapping in a GHashTable.

I hook "some" (many) of the cairo drawing calls, and look up the context
in my hash table. If matched (it should be), two calls are made - one
for the original context, one for the corresponding .pdf context.

For larks, I've also caused a new .pdf page per context - to see what
gets drawn. Doing this, I get lots of lovely bits of widget, all in
vectors**, and all roughly in the right place. (It appears that GTK is
using one big drawable deep down.)

So far, I've got no text, (I didn't hook any text drawing functions),
and I don't appear to get any pixmaps. (Those could be drawn with GDK
primitives - I've yet to port them to cairo).


**:

For some reason, cairo 1.4.2 (as supplied by ubuntu) would grind like
mad when asked to output a .pdf page with a gradient on it (as supplied
by clearlooks). It appears that it was being forced to fall back to
image rendering - and it really did grind.

Having applied Adrian Johnson's patches I discovered at
http://lists.freedesktop.org/archives/cairo/2007-March/010097.html
this problem was sorted.

> And finally, you talked about starting up the program to be
> screenshotted and informing it to arrange itself as desired. A much
> more interesting approach would involve putting an unmodified
> application into the desired state through whatever means, then
> signalling it in some fashion, and having GTK+ respond to the signal
> by setting up the PDF-targeting cairo context[*] and forcing a full
> expose to the application.

Behdad has put me onto a GTK+ patch
(http://bugzilla.gnome.org/show_bug.cgi?id=318807) which allows
re-directing of window-drawing to an off-screen pixmap, along the lines
of:

+gdk_window_redirect_to_drawable (GdkWindow *window,
+				 GdkDrawable *drawable,
+				 gint src_x, gint src_y,
+				 gint dest_x, gint dest_y,
+				 gint width, gint height)


Now.. we just need to ensure that GdkDrawable has a .pdf cairo surface
backing it. (I've yet to actually explore that patch. It seems like it
requires the application to execute this code voluntarily though -
although there might be "evil" ways LD_PRELOAD hooks into the
application and make it happen when at our will.

I'm still playing with the "snooping" and replay of cairo calls for now. 

Regards,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



More information about the cairo mailing list