Uti,
Looking further into your uncertainty about where temp comes from (see previous
email, below) reveals a possible memory leak.
NSBezierPath* temp; is in the list of declarations.
This snippet is in drawRect:
NSAffineTransform* tfm = [[NSAffineTransform alloc] init];
[tfm scaleXBy:scaleX yBy:scaleY];
temp = [tfm transformBezierPath:_path];
NSLog(@“\n\n temp = %p\n\n",temp);
drawRect runs many times while dragging the corner of the window.
transformBezierPath: creates a new object each time.
A new temp is created each time. Just one memory location is not used
repeatedly.
Here’s a list of temp addresses — not temp content — (from NSLog %p above)
while dragging the corner of the window slightly. They are all different.
2015-01-28 16:27:44.042 CVone[780:303]
temp = 0x608000320960
2015-01-28 16:27:44.094 CVone[780:303]
temp = 0x60800013fd60
2015-01-28 16:27:49.465 CVone[780:303]
temp = 0x6080003212c0
2015-01-28 16:27:49.484 CVone[780:303]
temp = 0x60000013ff40
2015-01-28 16:27:49.501 CVone[780:303]
temp = 0x608000321180
2015-01-28 16:27:49.523 CVone[780:303]
temp = 0x608000320be0
2015-01-28 16:27:49.541 CVone[780:303]
I hope ARC keeps cleaning them up. Or do I have a memory leak? If so, I’d
appreciate some guidance on how to fix it.
Nick
On Jan 16, 2015, at 5:30 AM, Uli Kusterer <[email protected]> wrote:
> On 15 Jan 2015, at 07:58, Quincey Morris
> <[email protected]> wrote:
>> Putting those two ideas together leads to a better approach. Create the
>> bezier path once, relative to an arbitrary bounding rect — say 1000 x 1000.
>> (But any rect would do.) When you need to draw the path, set the CTM of the
>> context to scale 1000 x 1000 (the reference bounds) to the context’s width x
>> height (the view bounds). Then just draw the original path and AppKit will
>> scale the bezier path for you.
>
> That's not the be-all end-all, though. Scaling the CTM scales line widths and
> heights as well. So if you for example want to skew the path, you'd get lines
> that are wider than they are tall (kind of calligraphic). Also, changing the
> CTM means that mouse click coordinates will be in a different coordinate
> system then your drawing, so if you’re e.g. implementing a graphics editor,
> you'll have to manually translate the coordinates each time.
>
> A better idea might be to have a list of original objects and projected
> objects. The list of projected objects is generated by transforming the
> paths. Whenever your view's bounds change, you rebuild this list of projected
> objects from the originals (thus keeping rounding errors etc. to a minimum as
> they can't accumulate). The drawing code just draws this projected list.
>
> As I don't know where 'temp' comes from in N!K’s code,
NSBezierPath* temp; is in the list of declarations.
_path is created once, in -(id)initWithCoder:(NSCoder*)coder .
_path is scaled to the new size and assigned to temp each time drawRect is
called. Thus, there is no error buildup.
> this may be what's already happening, in which case I find that a better
> approach than mangling the CTM if your interest is in having a shape drawn
> crisply in a window. If you're instead looking to scale a drawing (whether
> vector or otherwise), where you want lines to be skewed, then Quincy.s
> approach is preferrable.
>
> -- Uli
Nick
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
