Cairo api for standard display API, back-cairo redesign & saving/restoring state to not destroy the current path.

[Banlu Kemiyatorn]

We were discussing once, long time ago, about exposing cairo API
as a standard display method. GTK+ is going to do that hence
may be we want to consider doing that as well. Since the basic apis are
similar, and no, I don't want cairo dependency because we don't
need it, may be a set of dummy functions should be useful along
those DPSops. The back just need to return the current context
of cairo, and if cairo backend isn't running, return GSCurrentContext()
and things fall under those dummy cairo apis that will simply convert
arguments into DPSops. What would be a clean way of doing this?
This sounds troublesome if the gui compiled with dummy cairo functions
while the back-end is actually real cairo, doesn' it? Or the back may
try to detect if the cairo functions are dummy or not.. What would
lib loader do if 2 function names are identical?

Another thing is, I am thinking if copying cairo context between
graphic state saving and restoring is better than using cairo's
save and restore on a single context directly. The problem is
that each cairo state isn't extensible. (While we want to extend
it for specific thing like fill/stroke color) This should be solved by
using an external stack to track the current graphic state of cairo.
One DPSgsave increase stack pointer and so on. Though,
I am too busy to volunteer to do this any time soon. Just wonder
if it is a better idea than the current method or not.

One last thing, I have heard that pdf model won't copy the current
path when saving and restoring state? Cairo is going to take this
approach as I understand it. There are good reasons behind this,
what if we can provide method that can save/restore state without
copying/destroying the current path... may be DPFgsave/grestore?