Re: NSTrackingArea message lag
Re: NSTrackingArea message lag
- Subject: Re: NSTrackingArea message lag
- From: Quincey Morris <email@hidden>
- Date: Thu, 26 Jun 2008 02:01:08 -0700
On Jun 26, 2008, at 00:51, Markus Spoettl wrote:
On Jun 26, 2008, at 12:19 AM, Graham Cox wrote:
Why do you need to use tracking areas? I doubt that they are
designed to handle hundreds of small regions. If you are dragging
within the view, just hit-detect the rects yourself and mark them
as needing update. If you need that to happen with just the mouse
passing over the view (button not pressed) you can turn on
mouseMoved: events and do the same thing.
Tracking events are awkward at the best of times, and are mostly
intended for cursor management. I think you'd find a more
conventional approach a lot more fruitful.
Well, it certainly doesn't sound like that in the guide. There's no
indication whatsoever that tracking areas are meant for cursor
rectangle updates only, this is just one way to use them.
The documentation discourages using mouseMoved: events and
encourages use of tracking areas. I can also see why. If I do it
using mouseMoved: messages I basically have to do everything that
tracking areas provide manually. There is no reason why the system's
implementation should be any slower (it's exactly the same task).
So, following the documentation, I was convinced that that's the way
to go.
Tracking rectangles were perhaps mostly used for dealing with cursors.
Tracking areas (NSTrackingArea) are useful for more things.
The NSWindow documentation used to (and I suppose still does)
discourages use of setAcceptMouseMovedEvents. The mouseMoved events
generated by tracking areas (NSTrackingMouseMoved option) aren't
discouraged, because they only occur upon movement inside the tracking
area, and the mouseMoved message is sent directly to the tracking
area's owner. You do *not* need to setAcceptMouseMovedEvents:YES to
use these tracking area mouseMoved events. You don't even have to test
if the event belongs to the view, since you know it does. You just
have to do a simple rectangle check to find out which of your rects
you hit (and with your original implementation, don't you still have a
few lines of code to work out -- from the tracking area in the
mouseEntered event -- which rectangle was hit?).
Maybe the best way to settle the original question is to profile the
performance with Instruments, and find out what's really taking up the
time.
_______________________________________________
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