Honestly, you'll just have to set them up again. In almost all cases
this will be cheaper than inverting the CTM to, and you can always
try to rearrange your drawing order to avoid having to setup a
lot of
state each time.
Set them again to what values? The context parameters might be set
by the outside code (e.g. written by other team) so at the point
where you need to do this you just don't know them (e.g. you are a
plugin and there is no easy way to "rearrange" the drawing order).
And there are no getters for most (or all?) context parameters
(e.g. the above mentioned alpha) to be able to grab them all and
reset them later... Besides, when your code (e.g. a plugin) first
gets the context, the context might already have a non-identity
CTM...
The plugin case is actually a good example of why saving and
restoring the gstate really is the better way to go.
Your comment is that the context might have a non-identity CTM on
entry to the plugin, and therefore saving and restoring the CTM
won't get you back to identity. But typically, you wouldn't _want_
to get back to identity in that case. The CTM has been set up by
the host application in whatever way that the host app deems
appropriate. Maybe the host app is displaying a magnified view of
the plugin content so it's passing in a CTM with a 2x
magnification. If you revert all the way back to an identity
matrix, you'll lose the magnification. You really want to revert
back to the CTM state that the host app provided.
As far as setting up other context values, if you save the CTM
state right at entry, then any changes to CTM state have been
applied by code that you called. You should be able to call that
code again.
Whether you started with an identity CTM or not, there might be good
reasons to go back to the "initial transform" (however that's
defined) without losing the context's saved state stack in the
process. You could even do a save/restore around that reset so you
could go back to where you were.
Having a function to set the transform (not just concatenate to the
current one) would allow you do do that, don't you think?
steve
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden