Re: Good mouse tracking design for dynamic view?
Re: Good mouse tracking design for dynamic view?
- Subject: Re: Good mouse tracking design for dynamic view?
- From: "Michael Ash" <email@hidden>
- Date: Thu, 26 Jun 2008 17:40:33 -0400
On Thu, Jun 26, 2008 at 2:20 PM, Nathan Vander Wilt
<email@hidden> wrote:
> I have a view that displays and allows interaction with a lot (hundreds,
> even thousands) of small items. I am having trouble nailing down a good
> design for event handling, and just as I was ready to plead for help I see
> some other NSTrackingArea discussion that perhaps sheds a little light, but
> still inconclusive.
>
> It seems tidy to clear and reset all my tracking areas as the view gets
> redrawn, but that leads to situations like where an item moves relative to
> the mouse instead of vice versa, and since tracking areas can't be moved,
> the mouseEntered->mouseExited transaction gets killed halfway through with
> the old tracking area.
>
> My problem is that the displayed items can get updated (moved, deleted,
> etc.) in situations like this:
> 1. The user mouses over an item, its tracking area fires, and some status
> text elsewhere gets set to reflect what's under the mouse.
> 2. Before the mouse moves away from the item, the item moves and its
> previous tracking area is deleted. So now I never get that mouse exited
> event, even though the status text should be cleared.
>
> So it seems I need to do more bookwork myself, but I'm wondering which
> direction others would recommend:
> a) Set up a single tracking area for the whole view, and perform all my own
> hit testing every time the mouse moves.
> b) Keep the per-item tracking areas, but perform my own testing in the edge
> cases when active (mouse has entered but not exited) tracking areas are
> getting reset.
I vote for option A.
Efficiency should not be a concern. Unless your hit testing is
completely ridiculous, it will execute orders of magnitude faster than
the user can move his mouse. I have an app which sets the cursor based
on hit testing against a potentially large collection of NSBezierPaths
and have never heard of any performance difficulties in hit testing.
Drawing, yes, but not the cursor management (which is what I use it
for). If you can currently use tracking areas then your areas ought to
be plain rectangles, which are vastly faster than NSBezierPath to hit
test against.
Reinventing hit testing shouldn't be much of a concern either,
especially if your areas really are rectangles. Testing whether a
point is inside a rectangle is a one-liner using NSMouseInRect, and
you can basically just stick a loop around that and be done.
Done properly, you can factor the update-status-text code into a
separate method, then call it every time the mouse moves or anything
else changes. Just remember to take into account clipping if your view
is scrollable, you don't want your status text changing because the
user mouses over where something *would* be if it weren't off the edge
of your view.
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