Re: Optimizing NSView's drawRect
Re: Optimizing NSView's drawRect
- Subject: Re: Optimizing NSView's drawRect
- From: David Chan <email@hidden>
- Date: Fri, 25 Nov 2005 15:19:47 +0800
Hi All,
Thanks a lot for the informative replies on that matter. I am now going to
try finding where the memory possibly leak and sort out where and when to
release the object.
The book's coordinates would change as the window resize and zoomed and
therefore it might be rather tricky to store the information or image. It
may only works for situation where the drawRect is called by scrolling
action.
I will try to download the Shark too and see if I can better track the
problem.
Will report back when I find the exact problem and couldn't solve it using
above suggestions.
Thanks..
Regards
David
On 11/25/05, Uli Kusterer <email@hidden> wrote:
>
> Am 24.11.2005 um 05:00 schrieb David Chan:
> > I am still strugling with the 'release' part of obj-C as I have
> > been using
> > Java all this while, so I may have lots of object unreleased within my
> > function too. I don't know if that could result in the above problem.
>
> Search the archives of this list to see lots of different and very
> good explanations of how Cocoa management works. It's really not all
> that hard as there are simply a few distinct rules that you have to
> learn to manage memory in Cocoa. And if one of the explanations
> doesn't help, one of the others will usually explain it in a way that
> suits the way your brain is wired.
>
> Others have elaborated on how to get rid of those leaks. They're
> usually the main reason for slowdowns, because when you use too much
> RAM, parts that haven't been used for a while will get swapped out to
> disk, and hard disc access is one of the slower actions on a computer.
>
> But just in case you find that, after you've fixed the leaks, that
> your view still takes a lot of time to draw, you might want to look
> into common techniques for speeding up your drawing, e.g. by only
> drawing the parts that actually changed or need redrawing. To find
> out what needs redrawing, look at the rect that is passed as a
> parameter into drawRect:. If it doesn't intersect this rectangle, you
> don't need to redraw it.
>
> If your view doesn't change very often, but is redrawn a lot, you
> can also use various caching schemes to e.g. draw stuff into an
> NSImage when your view actually changes, and to simply copy parts of
> that NSImage to the screen inside drawRect: when nothing's changed
> but you need to redraw e.g. during scrolling. As always, there's a
> danger of caching too much and thus using up a lot of RAM here.
>
> Others have already mentioned how you can coalesce several
> successive update events. I just thought I'd mention the term
> "coalescing" as that's what Cocoa calls it internally e.g. when
> combining screen refreshes and notifications.
>
> Cheers,
> -- M. Uli Kusterer
> http://www.zathras.de
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden