Re: How to Optimize drawRect: for obscured views?
Re: How to Optimize drawRect: for obscured views?
- Subject: Re: How to Optimize drawRect: for obscured views?
- From: "E. Wing" <email@hidden>
- Date: Sun, 12 Nov 2006 16:07:56 -0700
It's an OpenGL view, so sub-rects tend to be less helpful.
Thanks,
Eric
On 11/12/06, Mike Abdullah <email@hidden> wrote:
I don't know what your view does, but it may make sense in your
animation to only use setNeedsDisplayInRect: to improve performance.
Mike.
On 12 Nov 2006, at 01:21, E. Wing wrote:
> On 11/11/06, Andrew Farmer <email@hidden> wrote:
>> On 11 Nov 06, at 16:46, E. Wing wrote:
>> > I have a custom view which may have animation. I use an NSTimer to
>> > fire periodically and I check to see if anything is animating in my
>> > view. If so, I call setNeedsDisplay:YES.
>> >
>> > If I minimize or hide the application, I notice that drawRect:
>> stops
>> > being called by the system (which I consider good). But if my
>> > view/window is completely obscured by another window (say another
>> > window from my app or from another application such as Safari) , I
>> > noticed that drawRect: is still being called.
>>
>> Yes. That's intentional; while your view may not be exposed at that
>> given moment, it's entirely possible that something the user does -
>> like hitting the Exposé button or moving another window out of the
>> way - may show your view's contents. Due to the way that OS X
>> handles windows, your view *does not* have to redraw when this
>> happens; it gets this functionality "for free" from the window's
>> backing store.
>>
>> As far as a solution goes? You could check to see if the window
>> containing the view is frontmost, and slow down the drawing timer
>> if it isn't. This probably isn't ideal (some users may want it to
>> update normally in the background!), so you may want to make it
>> optional, and configurable in the preferences.
>
> Yeah, this isn't really ideal since I actually intend non-frontmost
> views to be viewed. I just wanted to spare some processing cycles for
> when there are so many, you can't see them all. So I wanted to find
> those views that are currently hidden and bypass updating for those.
>
> But maybe a user option to throttle back update speed as you suggest
> is my best and only recourse. So, two questions. First, what is the
> API call I need to figure out if my view is frontmost? (I was looking
> for it for a different reason but haven't found it yet.) Second, is
> there a way I can reuse my existing timer to set my new timer
> interval, or do I need to release my old timer and create a new one?
>
> Thanks,
> Eric
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> 40gmail.com
>
> This email sent to email@hidden
_______________________________________________
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