Re: Optimizing NSRectFill
Re: Optimizing NSRectFill
- Subject: Re: Optimizing NSRectFill
- From: "Michael Ash" <email@hidden>
- Date: Sun, 21 Dec 2008 16:45:43 -0500
On Sun, Dec 21, 2008 at 3:58 PM, Glenn L. Austin <email@hidden> wrote:
> On Dec 21, 2008, at 9:43 AM, Michael Ash wrote:
>
>> On Sun, Dec 21, 2008 at 11:49 AM, Scott Ribe <email@hidden>
>> wrote:
>>>
>>> I guess what Mike is proposing is that redrawing in response to
>>> setNeedsDisplay is only deferred until the end of handling the current
>>> event? (And therefore only improves things when there are multiple calls
>>> on
>>> the same view.) This is at least consistent with the documentation, as
>>> far
>>> as I know. But I had assumed that somewhere the system was putting more
>>> of
>>> an effort into deciding when to redraw marked views. And my assumption,
>>> as
>>> far as I can tell, was also consistent with the available documentation.
>>
>> That is indeed what I'm proposing. In other words, you'll always have
>> this:
>>
>> event: invalidate view
>> view: redraw
>> event: invalidate view
>> view: redraw
>>
>> And never this:
>>
>> event: invalidate view
>> event: invalidate view
>> view: redraw
>
> I've seen both -- you can't guarantee one or the other.
>
> IIRC, user events have priority over system-generated events (like redraws).
I figured I ought to quit pontificating and offer some real data.
I wrote a really basic NSView subclass:
- (void)drawRect: (NSRect)r
{
NSLog(@"%s", __func__);
sleep(1);
}
- (void)mouseDragged: (NSEvent *)e
{
NSLog(@"%s: %@", __func__, e);
[self setNeedsDisplay:YES];
}
- (void)mouseDown: (NSEvent *)e
{
NSLog(@"%s: %@", __func__, e);
[self setNeedsDisplay:YES];
}
And then stuck it in a basic Cocoa project and tried it out.
The basic outline of what I said above appears to be correct. The log
always showed one event handling message followed by one draw, no
matter what I did.
However, something I didn't know: it appears that something coalesces
mouseDragged: events. They don't pile up the way I thought I would.
Rather, when you come back around, you only get one mouseDragged: with
the latest location. In other words, while the framework always
follows a consistent event, draw, event, draw sequence (at least in my
testing) it will not build up a long queue of events simply from
dragging the mouse around.
It *does* build up a long queue by clicking. I can make the app freeze
up for an arbitrary amount of time by just clicking the mouse over and
over again in the view. So beware of that.
Also if you actually care about the path that the user's mouse took in
the time between drawing, you'll have to do something fancier. If all
you care about is following it around, it seems that there is no need
to do anything special. And note that this applies to slowdowns both
from crappy code (like mine) and from beam sync, so the OP who was
seeing a bunch of lag and very delayed processing of mouse dragged
events must have been seeing something else.
Mike
_______________________________________________
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