[cairo] Drawing to multiple surfaces, "cairo_recorder", zoom
Hakki Dogusan
dogusanh at tr.net
Sat Dec 15 03:35:23 PST 2007
Hi,
Tuom Larsen wrote:
>
>
> On Dec 14, 2007 11:13 PM, Carl Worth <cworth at cworth.org
> <mailto:cworth at cworth.org>> wrote:
>
> On Fri, 14 Dec 2007 22:47:40 +0100, "Tuom Larsen" wrote:
> > Hello. Yesterday's answers cleared up a lot but they provoked
> some more.
> > Please:
>
> No problem, that's what we're here for. :-)
>
> > - Say an application draws to a window and optionally, if a user
> would like
> > to, it exports the drawing to PDF. How?
>
> First of all, an application, (at least one targeting X or GTK+), must
> be prepared to redraw its contents, (or any portion of its contents),
> at any time. So an application has to have code for that already.
>
>
> But the drawing would be a raster image embeded in PDF, no? Well unless
> I switch to a vector surface target, as you suggest bellow?
>
>
>
>
> > If I understood Carl's
> > recommendation correctly -- to use "data structures [which] know
> how to
> > 'draw themselves' given a cairo context -- I probably could write
> some dummy
> > drawing functions (lineto, circle, stroke, ...) which would just
> record [1]
> > the drawing operations (and serialize to disk, e.g. in a text
> file). Later,
> > I could parse that file and execute the real drawing function of
> a given
> > surface. Does it make sense to you?
>
> No, that's not what I was describing at all. I'm just talking about
> using the same code that made the stuff appear on the window in the
> first place. Call that same code again with a cairo_t* targeting a PDF
> surface instead of the cairo_t* targeting a surface for the window,
> and you should be done.
>
> Am I making sense yet?
>
>
> Yes, I see, thanks. But consider this:
> - The drawing is the result of some heavy computation - now it would
> have to run twice.
> - Or even worse, the result of some stochastic processes.
> - How to pass the targeting surface through network or pipe? (Simple,
> you [I] don't. You [I] send the drawing source code.)
> Please, I certainly don't want to exaggerate.
>
>
Regarding "cairo_recorder", I did something similar for
printing/previewing in my wxPrintCommandProcessor. As suggested before,
it records wxDC's drawing commands in a list, (so, only result of heavy
process is required to saved), then it replayed to either to screen or
printer. If I would do it for Cairo, it would look something like :
struct command {
virtual ~command(){}
virtual void play(cairo_t *cr)=0;
};
command_line_to : public command {
double m_x, double m_y;
command_line_to(double x, double y):m_x(x), m_y(y){}
virtual void play(cairo_t *cr){ cairo_line_to (cr, m_x, m_y); }
};
etc.
Hence, instead of calling Cairo API directly, generate commands, save
them somewhere, than iterate & play them against a real cairo_t.
--
Regards,
Hakki Dogusan
More information about the cairo
mailing list