Re: Shadow Scaling
Re: Shadow Scaling
- Subject: Re: Shadow Scaling
- From: Gordon Apple <email@hidden>
- Date: Sat, 22 Dec 2007 18:47:59 -0600
Ah, Thank you , thank you. That is the type of information I was hoping
to elicit. I haven't had a chance to delve into that yet, but it should
prove useful.
I re-architected my code to use a single NSShader in my rendering code,
rather than putting one into each of my shadowed objects. In one case I use
the scaled scroller used in Sketch and lifted and modified the related
Sketch code for part of my own sizing controller. Since it had the bound
scale factor, I set an outlet in my renderer to access that factor and then
use it to scale the shadow offset and blur radius when rendered. Not as
clean as I would like since it broke some of my encapsulation, but it works.
That same sizing controller does double duty (depending on how it is
connected) in my down-scaled preview windows, but I haven't addressed that
one yet.
One thing I noticed, unless it's an optical illusion, that the visible
blur radius scales, but less than linearly. I suspect that there is
something about the density of algorithm computations that causes that. The
disparity becomes more obvious as the scale increases.
BTW, is there some reason why NSGradient is (at least colorwise)
immutable? I currently attach one to each shaded object but would prefer to
use only one in my renderer (as described above for shadows). If done in
the renderer, every draw operation requires a new NSGradient object, which
should keep the garbage collector employed. (Sometimes I really miss stack
objects. :-)
> Shadows draw relative to what core graphics calls the 'base' ctm,
> which is a transformation matrix independent from the one that applies
> to normal drawing. This matrix isn't directly accessible. It's set
> up to be the identity matrix usually, but if there's a user space
> scale factor (as used for resolution independence, settable in Quartz
> Debug), then it scales by that scale factor. This is the same as the
> transformation applied to the contentView of a window by default.
> (The scale factor can also be retrieved with -[NSWindow
> userSpaceScaleFactor].)
>
> You want your shadows to behave as if they draw in the space of your
> view itself. That isn't how it works, but you can emulate the effect
> by just keeping track of what coordinate space everything is in.
> Instead of setting offset and blur radius on your shadow object, you
> want clients of your shadow to set new properties
> userSpaceShadowOffset and userSpaceShadowBlurRadius. Then when the
> -set method is called on your shadow object, you can use methods like
> -[[NSView focusView] convertSize:toView:] to convert the
> userSpaceShadowOffset and userSpaceShadowBlurRadius to parameters in
> the space on the contentView, then set a shadow with that offset and
> blur radius. That will work, because that's the space that
> CoreGraphics interprets the numbers in. Make sense?
>
> Hope that helps.
> -Ken
>
> PS - if it seems more clear to you, you can work directly with
> matrices instead of converting between coordinate spaces of views.
> CGContextGetCTM([[NSGraphicsContext currentContext] graphicsPort])
> gets you the standard transform matrix in -[NSShadow set]. You'd have
> to calculate the 'base' transform matrix yourself using the info in
> the first paragraph of this message.
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden