• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSTrackingArea message lag
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSTrackingArea message lag


  • Subject: Re: NSTrackingArea message lag
  • From: Graham Cox <email@hidden>
  • Date: Thu, 26 Jun 2008 18:14:46 +1000

I'm not saying that's definitely the problem, but to find out for sure you'd need to try both and see how if profiles.

Tracking rects are not exactly the same task as testing the rects yourself, because the system has to determine when the mouse actually enters and exits those areas, package the result into an event and dispatch it. It might also be doing this in a way that is constrained by time, or only testing one rect per loop, for example (all of which would be acceptable ways to reduce the event bandwidth for cursor- tracking use). Hit-testing a list of rects within your view should be straightforward, fast and optimised to the task in hand.

You didn't say if you were doing this on a mouse drag or a mouse move. If on a drag there is no reason to do anything but your own hit- testing - it will always be much faster than using events.

Graham



On 26 Jun 2008, at 5:51 pm, 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.

It appears I stand corrected.

Regards
Markus
--
__________________________________________
Markus Spoettl


_______________________________________________

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


References: 
 >NSTrackingArea message lag (From: Markus Spoettl <email@hidden>)
 >Re: NSTrackingArea message lag (From: Graham Cox <email@hidden>)
 >Re: NSTrackingArea message lag (From: Markus Spoettl <email@hidden>)

  • Prev by Date: Re: NSTrackingArea message lag
  • Next by Date: Re: [NSOutlineView] Saving/Restoring the hierarchy disclosure state (Reloaded)
  • Previous by thread: Re: NSTrackingArea message lag
  • Next by thread: Re: NSTrackingArea message lag
  • Index(es):
    • Date
    • Thread