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

[Nicolas George]

Hi.

I would like to discuss three features that I dearly miss from Cairo, and
that I intend to implement, either as a patch to Cairo or as an external
library, unless it is shown to me that I can do without it.

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.

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.

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. And it would put an end to the hope of zooming and
printing.

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;

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

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

(I am aware that the last feature would allow to emulate both others, but
they are all natural and useful per se.)

Now, the technicalities. These three features need an actual graphics output
to work on, or several of those; I will call them "backend". They also
provide an interface to the programmer; I will call them the "frontend".

First, the backend. In the context of Cairo, the only possible meaningful
backends are cairo_t and cairo_t. Since once of the requirement is to be
able to render the graphics operations at various scales, it must be an
object where transformations can already have been applied, which leaves
only cairo_t.

Then the frontend. The possible options are again cairo_t and
cairo_surface_t and a brand new object type. The latter option is the
easyest, but prevents from using the new features with parts of programs and
libraries already designed for Cairo; furthermore, it requires a duplication
of the API, which is not good. A cairo_t would probably be the most logical,
but this object does not hold a bunch of pointers to functions to customize
its behavior, only the cairo_surface_t has that.

It may be a good idea to add a level of indirection for the drawing
operations on cairo_t.

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.

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/20061223/c1902ea2/attachment.pgp