Gilbert Baumann's notes, copied from clim-cairo-2005-03-20/cairo-medium.lisp.

;; - blitting
;;
;;   The X11 Cairo backend currently crashes my X server when blittering from
;;   one surface to itself. [That is, if we draw to a surface using very same
;;   surface as the pattern].

[ Well, no X11 here anywore.  Is anything like this still relevant? ]

;; - pixmaps
;;
;;   These should be easy to provide.

[ David: done ]

;; - alpha impedance mismatch
;;
;;   Cairo uses pre-multiplied alpha while CLIM doesn't. So we need to convert
;;   things around as needed.

[ David: ??? ]

;; - real general designs and optimization short cuts

;; - new drawing options:
;;   - :transform-glyphs-p
;;   - :alu

;; - MEDIUM-DRAW-ELLIPSE*
;;   Need to find a good bezier approximation of circles.

;; - MEDIUM-BEEP

[ David: nix is, gepiepe kann ich nicht leiden. ;-)  Ein "visual beep" waere
  aber schick.  Vielleicht kann man da ja was basteln? ]

;; - device text styles

;; - find a substitue for CAIRO-FONT-SET-TRANSFORM

;; - abolish this silly CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS

;; - INVOKE-WITH-DRAWING-OPTIONS

;; - care for the proper text transformations.

;; - we need a systematic overview about what drawing option components are
;;   transformed under what circumstances in cairo and in clim.

;; - i believe a "cr" is really nothing more than a kind of graphics context, so
;;   this time implement a proper cache for those, so that we spend less time
;;   tossing options around.

[ David: Hmm, let's do some profiling before setting up a cache.  Cairo
  people seem to recommend creating a cairo context for each and every
  redraw and then throwing it away, and we only create one for every
  medium, so that shouldn't be too slow.

  What's important is to not leak the cairo context.  Right now I let the
  sheet destroy contexts when the mirror is destroyed, is that the right
  thing to do? ]

;; - more alu operations in clim
;;
;;   For CAD applications it is really handy to have an OR operation. (Which
;;   could be approximated in effect with :saturate). We would need to extend
;;   the CLIM general design specification to include alu operations. [As
;;   currently there really are only the OVER and FLIPPING operators available].

;; - More proper separation of a vanilla Cairo media and specific Cario medium
;;   like X11, Glitz, PNG, PDF etc.

;; - a WITH-CAIRO macro which can setup the proper FPU mode to make it break
;;   less.

[ David: oh yes, that's what I had to do in WITH-GTK.  Terrible.  ]


;;;; NOTES

;; RESOURCES, WHO TO FREE IT? -- It seems that if you destroy a window, a Render
;; picture associated with said window is also destroyed.
;; CAIRO-SET-TARGET-DRAWABLE and perhaps CAIRO-DESTROY do want to destroy that
;; picture on their own. So when we destroy a window we need to know all cairo
;; contexts floating around which associate to the window at hand and target
;; them at the root window (or better the spare window, more below) before we
;; destroy a window. And we need to do this recursively. And we need the extra
;; book keeping.

[ David: nix verstehen.  Was ist denn ein render picture?  Hilfe! ]

;; UNGRAFTED MEDIA -- It happens that an application wants to use a medium
;; before its sheet is grafted. In those situations we'd need a spare window to
;; target the associated cairo medium at. We could use the root window, but bad
;; things happen if the user actually does some drawing instead of merely
;; querying stuff like text extents. So I want to allocate a specific unmapped
;; spare window for those occasions.
;;
;; [There really are two situations: a) using an ungrafted medium, b)
;; using a medium that is grafted to a sheet which itself is not
;; grafted].

[ David: I'm using the root window for text size operations (harmless)
  and completely ignore drawing operations otherwise. ]

;; FLIPPING INKS -- Cairo can't and for ideological reasons perhaps never will
;; support flipping inks. I myself hate flipping inks even more so than
;; bit-blittering, but there are still a few ancient applications around, which
;; use it. So we'd need to think about some way to support it. One idea is to
;; render the shape to an A1 temporary pixmap surface and use good old X11 to
;; make that pixmap flip pixels around. This breaks some abtractions established
;; by Cairo and will perhaps stop working around 2012. The fun thing is:
;; Flipping will now turn into a rather slow operation.

[ David: I have implemented this strategy now.  We draw flipping ink to
  a gdk pixmap, then copy that over with GDK_XOR.  And indeed, Goatee
  now is extremely slow over remote X because it uses flipping ink.
  FIXME: Although simple cases work, sometimes flipping ink now causes
  garbage output to appear.  ]

;; - flipping ink
;;
;;   Below is some example code to make Cairo render the alpha channel to a one
;;   bit depth pixmap on the server. This pixmap can then later be used with X
;;   Core requests to flip pixels around. Still, in general flipping inks don't
;;   play nice when you have an alpha channel.
;;
;;   But: A flippink can't be solved by just setting up the proper Cairo pattern
;;   to a Cairo context, but drawing the shape itself must happen on our
;;   temporary surface.

[ David: see above for my implemenation of flipping ink.  Not sure how the
  alpha channel is meant to be handled though. ]
