[Cairo] Suggestion for replacing cairo_copy with set_gstate.
Bill Spitzak
spitzak at d2.com
Fri Sep 26 15:12:40 PDT 2003
What I was recommending is that there only be cairo_t objects avaialble to
the interface. The cairo_gstate is entirely internal.
> Perhaps instead we just want a single function to copy the graphics
> state from one cairo_t to another. Perhaps drop cairo_copy and add
> something like:
>
> cairo_set_graphics_state (cr, copy);
Yes this is exactly how I think this should be done, though in some email I
was writing I used the name cairo_copy_state(cairo_t* to, cairo_t* from).
> And then if the user wants to hold on to just the graphics state, they
> can just use a proxy cairo_t for that.
> Does that make any sense? Hopefully I'm not talking in circles.
This exactly matches what I'm thinking. This would remove any need for any
references to gstate objects to be passed to/from cairo calls. I think all
the interface can be done with cairo_t objects.
I'm also wondering if the "surface" object is needed. I could see instead
that you use a cairo_t object whenever a surface is needed (such as the
source for a comp), the surface being of course the current surface of that
cairo_t's top gstate. Plausable advantages are the ability to push/pop the
source for operations, or to refer to the CTM or other state of the source,
but mostly it is to reduce the interface to a single object. Something about
this idea appeals to me, though I'm not sure what.
> This goes to the issue of error handling. See my future email. ;-)
Yes I read that, seems like a good idea. Otherwise people may never notice
that they are producing errors. One thing though: if errors stop push/pop
from working, it will be difficult to get back to a known state. Then again
doing a mismatched set of push/pop would also be an error and cannot be
recovered from. Perhaps the "clear errors" function should also clear out the
stack and only keep the stat the cairo_t was created with. Alternatively
there can be no way to clear errors except to destroy the cairo_t, though I
can see that being a pain and force some libraries to have to wrap the
cairo_t pointer in another object.
PS: I finally have a RedHat 9 machine so I will be able to compile and work
on this stuff, instead of just blathering on about it here on the mailing
list.
--
,~,~,~,~ ~ ~ ~ ~
/\_ _|_========___ Bill Spitzak
~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com
More information about the cairo
mailing list