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

[Kalle Vahlman]

2006/12/23, Nicolas George <nicolas.george at ens.fr>:
> Before explaining these features, I would like to expose the rationale
> behind them. When I was young and only knew DOS, giving simple
> graphics feedback from a program (a computation for example) was
> easy: a simple function call would set the screen in graphics mode, and
> drawing primitives would be directly available (at the end, waiting for a
> key and restoring text mode was considered good practice, although not
> necessary). It was not pretty, but pretty is not always a goal.
>
> With windowing systems, things are always more difficult: graphics
> program need to handle asynchronous exposures to their window. A
> library that would take care of all that and expose just a simple API is
> something I have been looking for for a long time. If it had some
> additional features, like zooming or printing, all the best.

I don't see the point in this comparison. The only reason DOS didn't
have the notion of exposure is because it has no windows. There is no
need for constant updates since the video memory showed onscreen is
not changed in the between. It is natural that a system with windows
behaves differently, since the contents of all windows can't be in
video memory all the time (well, with limited amount of windows it
could, but that's not realistic).

> The drawing primitives provided by Cairo are really good, I would be more
> than happy to be able to use them for that purpose. Unfortunately, as far
> as I know, Cairo used on a window surface will require just the same
> handling of events by the main program.

Of course, but that's not different with drawing with any other system
in a windowed environment. This portion of your problems sounds like
something existing toolkit libraries are doing (GDK in the GTK+ case
for example).

> To handle expose events, the current picture must be saved. A solution is
> to draw in a pixmap, and force redraws of the pixmap sometimes. But
> this really an ugly solution.

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.

> And it would put an end to the hope of zooming and printing.

The data you draw is still there, you can redraw with the approperiate
scaling for zoom. With printing, the DPI and output size differ from
the screen so you'd want to take that into account.

> To do things cleanly, three features are required:
>
> - to be able to record the drawing operations issued by the program, and
>   replay them later, at a different scale or on a different surface;

For the paths, this is already possible. You can get the current path
of a cairo context and render it to another one. For other things like
patterns I'm not sure (someone else should comment on that...).

> - to be able to duplicate drawing operations to two surfaces, like the tee
>   utility, to achieve efficient immediate display and at the same time
>   record the operations for redraws;

Having multiple cairo surfaces as a destination  sounds like an
interesting idea indeed, though again I'm not sure how feasible it
would be to implement. The result of drawing already can be duplicated
by painting with having a surface as source.

> - to be able to serialize and unserialize drawing operations, to send them
>   from one process to another, to avoid clumsy lockings problems
> inherent to   threaded programs, and allow the windows to survive the
> end of the program (like the -persist option in gnuplot).

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

I think it's more beneficial to have cairo threadsafe than circumvent
the problem with a "wire format".

> Before I carry on ranting about these feature, and obviously before
> starting to code, I would like to get some feedback, if someone have
> advice.

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.

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