[cairo] Vector screen capture with Cairo

[Carl Worth]

On Wed, 04 Apr 2007 22:53:24 +0100, Peter Clifton wrote:
> It does seem to create and destroy these farily often - e.g. mousing
> over a toolbar, I'm seeing things like:
>
> cairo_xlib_surface_create( 0x8124770, 60818447, 0x8128cb8, 900, 650 ) =
> 0x833a648
> cairo_create( 0x833a648 ) = 0x83382e8
> cairo_destroy( 0x83382e8 )
> cairo_surface_destroy( 0x833a648 ).

Yes, GTK+-using programs will create lots and lots of cairo
contexts---one for every expose-event handling function in the
program. But if you're lucky these will all be targeting the same
target surface, (and then all you need to get PDF output is to create
a PDF target surface instead).

> I've probably not got enough time to dig deeply into that, but meta
> surfaces do sound like they could be key to this kind of problem, the
> still vector based "final" product of a series of drawing operations?

Yes. Any of the SVG, PS, and PDF surface backends in cairo are all
implemented internally with cairo-meta-surface.c, (and
cairo-analysis-surface.c on top of that). The important point is that
the meta-surface records each high-level cairo operation (as vectors)
and those recorded operations are then replayed in the end to create
the actual PDF output.

So, if in fact everything in your application of interest is targeting
a single surface, then all you should have to do is get a PDF surface
in there and you'll be done.

If, instead, your program is targeting multiple intermediate surfaces,
then you may run into some rasterization for those until some of the
subsequent work I described is completed. (But even with that
limitation you might be just fine.)

Oh, and I think someone mentioned a proxy X server approach. That's
really not interesting as it would capture information at a much lower
level than what you really want, (for example instead of a path and a
stroke operation you would get a huge list of trapezoids to be
filled). Plus you wouldn't have all the PDF-generating machinery that
already exists in cairo. So not an interesting approach at all,
really.

> I believe it does gdk calls though - and it looks fairly easily replace
> the Xlib primitives with cairo ones.

Right. I was just pointing out that you should expect to have to do
that to get a complete solution. It sounds like you've got that under
control too.

-Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070404/8cae3dcc/attachment.pgp