Skip navigation.
 
mlRe: What paradigm behind NSColor's drawing methods?
FROM : glenn andreas
DATE : Fri Feb 01 22:44:35 2008

On Feb 1, 2008, at 3:18 PM, Jerry Krinock wrote:

>
> On 2008 Feb, 01, at 12:47, glenn andreas wrote:
>

>> What circumstances are you running into that not having an explicit 
>> drawing context parameter is a problem?

>
> Drawing a focus ring, in -drawRect of a custom control...
>
> [NSGraphicsContext saveGraphicsState];
> NSSetFocusRingStyle(NSFocusRingOnly);
> [[NSColor keyboardFocusIndicatorColor] set];
> NSFrameRect([self visibleRect]);
> [NSGraphicsContext restoreGraphicsState];
>
> In the Cocoa Drawing Guide I read that:
>
> "Important: Saving and restoring the current graphics state is an 
> expensive operation and should done as little as possible. With the 
> exception of clipping paths, most state attributes can be undone 
> manually in your code without saving and restoring the entire state."
>
> They seem to be suggesting that instead of -saveGraphicsState and -
> restoreGraphicsState, I should manually "get" the color and the 
> FocusRingStyle before "setting", so I can set them back to their 
> original values after I am done.  But I can't do that because there 
> are no getters for these.
>


There's actually a lot of things that you can't do the "get old state, 
change, set back when done", including setting a shadow and (in some 
cases) change the transform (you can set the inverse of the transform 
to "undo", but that introduces precision errors and assumes that the 
transform has an inverse, which it won't for some degenerate cases), 
so I'd actually consider the guide to be misleading...

Note that the underlying Quartz API is the same way - there are very 
few "get current state" operations in comparison to the things you can 
set (9 CGContextGet... vs 36 CGContextSet...) and that 
CGContextSaveState and CGContextRestoreState are used all over the 
place (and I can't find any comment suggesting that you avoid using 
them because they are expensive - on the contrary, there are many 
comments about how you need to use them because that's the only way to 
do something).

I'd suggest filing a bug against any api that doesn't have a "get 
current" version, as well as against that documentation (since you 
obviously found that it didn't synch with your experience).

Remember, don't expect things to change if you don't file bugs - and 
filing them is like voting in Chicago (vote early, vote often).

In the mean time, use saveGraphicsState/restoreGraphicsState when you 
have to and don't worry about performance until Shark tells you it is 
a problem...


Glenn Andreas                      <email_removed>
  <http://www.gandreas.com/> wicked fun!
quadrium | prime : build, mutate, evolve, animate : the next 
generation of fractal art

Related mailsAuthorDate
mlWhat paradigm behind NSColor's drawing methods? Jerry Krinock Feb 1, 20:41
mlRe: What paradigm behind NSColor's drawing methods? glenn andreas Feb 1, 21:47
mlRe: What paradigm behind NSColor's drawing methods? Jerry Krinock Feb 1, 22:18
mlRe: What paradigm behind NSColor's drawing methods? glenn andreas Feb 1, 22:44
mlRe: What paradigm behind NSColor's drawing methods? Erik Buck Feb 1, 23:49
mlRe: What paradigm behind NSColor's drawing methods? Peter Ammon Feb 2, 01:23
mlRe: What paradigm behind NSColor's drawing methods? Erik Buck Feb 2, 03:29
mlRe: What paradigm behind NSColor's drawing methods? Ricky Sharp Feb 2, 16:04
mlRe: What paradigm behind NSColor's drawing methods? Jerry Krinock Feb 4, 19:59