[cairo] Meta surface proposal

Owen Taylor otaylor at redhat.com
Tue Feb 8 09:00:10 PST 2005


On Tue, 2005-02-08 at 17:28 +0100, Jost Boekemeier wrote:
> >(surface->meta_surface && !surface->replaying) 
> 
> What does "surface->replaying" mean?
> 
> I think your proposal touches two things.
> 
> First a "meta" surface which holds the
> resolution-independent drawing primitives.  This could
> (and should) be implemented on top of cairo [1].

Perhaps using the word "meta" here was a mistake ... brought
in everybody's hopes and fears. :-). It's conceivable that the same data
structures and code could be used in a public-API replayable surface,
but  really what I was talking about was

 cairo_internal_vector_surface_helper_t

That happens to record the drawing stream internally.

> Second your algorithm to make n passes to optimize the
> output for the target device.  Imho this makes more
> sense.  But I don't understand why this has to be
> implemented within cairo.

Where else? It is an algorithm that is needed for multiple types of
output device, that is most easily implemented at the level of a Cairo
backend. You can't implement it as a layer above Cairo because 
that means presenting a different drawing API to the application
programmer.

Implementing it as a layer below Cairo (I think what Keith is proposing,
basically) seems to me to make things harder for no good reason. It's an
architectural restriction that doesn't reduce the amount of code we have
to write.

> Why is the situation with windows printing different
> than the situation with PDF/PS on Unix?

It's not at all different from PS on Unix. You can't produce PS without
exactly the same algorithms. PDF is a little different in that
you can at least come fairly close to representing the full range
of Cairo in PDF. And given some work on ghostscript, you might be able
to convince ghostscript (which is already in the printing pipeline)
to do a good job of rasterization or conversion to PS so that you can
just use PDF as your printing format.

But the benefits of using PDF in the printing pipeline of, say, a
GTK+ program on Windows are very obscure to me. We generate a 
PDF file using Cairo. Then we use Cairo to turn that PDF file
into GDI calls. Why not just generate the GDI calls in the first
place?

> Of course the proposal could be implemented, but I
> fear that the algorithm costs too much time and
> memory.

It wouldn't be used if if the backend in use doesn't need it. And if
you do need it you can't get around spending the time and memory.
(OK, you can implement application level paging to disk to get around
the memory usage...)

Regards,
						Owen





More information about the cairo mailing list