Re: NSTrackingArea message lag
Re: NSTrackingArea message lag
- Subject: Re: NSTrackingArea message lag
- From: Markus Spoettl <email@hidden>
- Date: Thu, 26 Jun 2008 01:33:07 -0700
On Jun 25, 2008, at 11:57 PM, Quincey Morris wrote:
These statements are a bit puzzling. What does "redrawing" mean
here? Are you talking about what you do inside drawRect:, or what
you do to cause drawRect: to be invoked? Are you using
setNeedsDisplay: or setNeedsDisplayInRect: to trigger drawing, or
some other technique?
Redrawing means setting needsDisplay. I'm using
if (![self needsDisplay]) {
[self setNeedsDisplayInRect:rect];
}
I found the needsDisplay check to speed it up a little. rect is the
tracking area.
If you literally meant "the mouse is being dragged", you weren't
getting mouseEntered events (they're not sent during dragging unless
you ask for them, and you didn't ask for them in your tracking area
options) so what was causing drawing to be requested in that case?
The drag starts with mouseDown: and ends with mouseUp:. In between you
get mouseDragged: events. Every time such an event arrives, I update
the internal selection structure and redraw the view accordingly. It's
exactly the same drawing operation that happens when the tracking area
messages fire. The same code is executed (using different colors).
If you really "completely disabled redrawing", how were you
detecting lag? The lag you started out with was between mouse moving
and "redrawing", but if nothing was redrawn ... ?
Instant logging to a NSTextField showing an increasing integer
counter. As tracking areas events arrive at the view, the counter is
increased and the field is updated. With a higher number (20+) of
areas, the counter was not in synch with the mouse movement,
increasing its value well after the mouse has stopped. That means that
the mouse movement was not in synch with the tracking area event, so
tracking area events are delayed for some reason.
I'm wondering whether, even when you've suppressed the drawing of
rectangles, you're still flooding the graphics system with
setNeedsDisplay... updates, and *that's* what is slowing things down.
Drawing was suppressed, no call to setNeedsDisplay was made in the
test. There is no flooding the graphics system, so that's not the case.
P.S. An alternative approach might be to use a single tracking area
for your entire custom view, and do your own rectangle hit testing
on mouseMoved events that occur inside it.
As I explained in my reply to Graham Cox, the documentation suggests
that tracking areas are the way to go. There's no apparent reason for
me not to trust the documentation and per se no reason why the
system's implementation should be any slower than my own. I'd just be
implementing tracking areas myself, checking which rectangle the mouse
is in at the moment and firing events accordingly.
It appears that I'll have to do this. It's not a problem of
implementation, I was just wondering if there was a reason for it to
be lagging.
Also using mouseMoved: events requires you to set
setAcceptsMouseMovedEvents: on the hosting window. That means the
window has to do something for all views on it when only this one view
needs tracking. I thought that was a little overkill. Plus tracking
areas are really elegant.
Regards
Markus
--
__________________________________________
Markus Spoettl
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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