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 <witness.of.teacht...@gmx.net> wrote: > On 15 Jan 2015, at 07:58, Quincey Morris > <quinceymor...@rivergatesoftware.com> 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 (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com