Re: drawRect runs twice, bounds are changed in between
Re: drawRect runs twice, bounds are changed in between
- Subject: Re: drawRect runs twice, bounds are changed in between
- From: N!K <email@hidden>
- Date: Wed, 28 Jan 2015 20:05:29 -0800
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@hidden> wrote:
> On 15 Jan 2015, at 07:58, Quincey Morris <email@hidden> 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@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