Re: NSTrackingArea message lag
Re: NSTrackingArea message lag
- Subject: Re: NSTrackingArea message lag
- From: Quincey Morris <email@hidden>
- Date: Wed, 25 Jun 2008 23:57:38 -0700
On Jun 25, 2008, at 23:11, Markus Spoettl wrote:
I have double (quadruple actually) checked that the redrawing is not
the problem, the view draws very quickly. When the mouse is being
dragged over the view, the same series of redrawing events is
completely instant up to a bar count of more than 200. I've even
completely disabled redrawing as a result of tracking area events
and the lag is still there. So the drawing is not causing the lag.
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?
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?
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 ... ?
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.
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.
_______________________________________________
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