[cairo] RFC: duplicating, storing and serializing drawing operations

[Kalle Vahlman]

2006/12/26, Nicolas George <nicolas.george at ens.fr>:
> Le quintidi 5 nivôse, an CCXV, Kalle Vahlman a écrit:
> > No, that's not a requirement as long as recreating the portion of the
> > window that got the exposure takes less time than what is a resonable
> > update time for an on-screen element. For things that take more than
> > that, usually a backbuffer is created (in the way you mentioned).
> >
> > I'm not sure if that is purely ugly, but the other end to balance with
> > is performance. You _can_ draw without caching, but that's potentially
> > too slow.
>
> In these paragraphs and the ones above I snipped, you seem to miss my whole
> point, so maybe I was not clear in the first place.
>
> You seem to think about programs with a GUI. Such programs are necessarily
> built around an event loop, and handling exposures is just a matter of
> adding an event handler. But there are other programs that need to do
> graphics, and are built in a totally different way.

What I stated earlier was based on how the windowing systems tend to
work, nothing really (interactive) GUI-specific about it. If your
output goes to a window, you need to refresh the contents when it is
hidden and exposed again. How that happens is another thing, and if I
get you right, you'd like it to be recreated by a library between the
application and cairo (or an API in cairo itself) that has recorded
the drawing commands the application has used?

> For example, think of a program that computes the trajectory of something,
> maybe using some differential equation or something. Such a program will
> look like:
>
> double x = x_init;
> double y _ y_init;
> while(1) {
>     ...
>     x = x_new;
>     y = y_new;
>     printf("%f %f\n", x, y);
> }
>
> But a picture is easier to read than a list of numbers, so it would be
> useful tu be able to write "lineto(x, y)" instead of printf. Unfortunately,
> there is no room for XNextEvent in such a program, and adding it would
> require a lot of work; often, much more work than writing the calculation
> itself. Instead, I often end up piping PostScript commands to gs, which
> lacks comfort.
>
> That is why I am looking for a library that would allow me to just write:
>
> ...
> init_graphics();
> moveto(x_init, y_init);
> ...
>     lineto(x, y);
> ...
>
> and not worry about anything else concerning graphics output. Or, as I was
> unable to find such a thing, I would like to write one.

That sounds very useful indeed.

> > The data you draw is still there, you can redraw with the approperiate
> > scaling for zoom.
>
> Well no, the data is not still there, that is precisely why I want a library
> to keep it for me.

Yes, the example code was very enlightening on the intent of all this
:) but it still didn't invalidate everything I said.

> To do the link with what I was writing earlier, I can give an example
> implementation of the hypothetical library:
>
> static FILE *plotter;
>
> void init_graphics(void)
> {
>     plotter = popen("/usr/libexec/plotter_helper", "w");
> }
>
> void lineto(double x, double y)
> {
>     fprintf(plotter, "lineto %f %f\n", x, y);
>     fflush(plotter);
> }
>
> > I think it's more beneficial to have cairo threadsafe than circumvent
> > the problem with a "wire format".
>
> I do not see how thread safety may be an issue here. Could you be more
> specific please?

Ah, I didn't realize you were thinking about separate processes
(should read more carefully) instead of a threaded library that takes
care of the locking etc. I was simply pointing out that making cairo
do the locking would be more beneficial than that.

-- 
Kalle Vahlman, zuh at iki.fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi