[cairo] RFC: duplicating,
storing and serializing drawing operations
Nicolas George
nicolas.george at ens.fr
Mon Dec 25 16:24:51 PST 2006
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
More information about the cairo
mailing list