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

[Nicolas George]

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.

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.

My rant about DOS was just to underline that drawing libraries in
non-windowed environments provide such ease. With a lot of drawbacks and
limitations, of course, but still, it is really easy.

> 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.

>			 The result of drawing already can be duplicated
> by painting with having a surface as source.

I do not understand what you are evoking here.

> You mean like the X protocol?-) Or a more saveable format like SVG, PS or 
> PDF?

What I am thinking about is indeed quite akin to the client-to-server part
of the X11 protocol. SVG, PostScript and PDF do not feed the requirement,
because they are too complex to unserialize; furthermore, SVG and PDF work
with whole documents, not individual drawing operations.

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?

> While I'm not sure about the problem description you gave (handling
> exposure with only images) and whether they are a solution to the
> question of concurrent drawing, the things you propose most likely
> have other useful applications so they are in my opinion worth at
> least exploring further.

Thanks for your advice. I hope I made clearer what were the my objectives.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061226/f7051129/attachment.pgp