Re: Select a NSBezierPath
Re: Select a NSBezierPath
- Subject: Re: Select a NSBezierPath
- From: "M. Uli Kusterer" <email@hidden>
- Date: Tue, 21 Sep 2004 19:37:17 +0200
At 22:04 Uhr -0400 20.09.2004, Robert Clair wrote:
This is the best way to go for a general drawing program - if for no
other reason
than it will account for line-width and for non-Bezier objects
(images with or without alpha if you
draw them as an image mask for picking purposes).
So far I agree.
There is a caveat - if you have _lots_ of objects your colors might
be very close together in
which case you must be careful to turn off anti-aliasing and
interpolation - or else
you can wind up picking the wrong object. (Not a problem if you
check one object at a time
and clear the view each time, but I want to pick the object that is
the one visible to the user
in the view as it is drawn so I render the whole display list and then check.)
This sounds very slow. If you have lots of objects in your view,
that means you redraw the entire document each time the user clicks.
considering how slow Quickdraw Regions used to be for hit-testing in
games back when, I'd suggest you definitely do a rect-intersection
test and only redraw those objects that actually intersect the rect.
That will give you a dramatic speed-up the likes of which you
wouldn't have thought possible.
At 8:13 Uhr -0400 21.09.2004, Robert Clair wrote:
"much slower" ??? Perhaps literally true, but certainly misleading. The
rendering approach is "fast enough" - i.e. it will appear close
to instantaneous for a user. It was fast enough 10 years ago on a Sparcstation
and it is fast enough on a G4/G5.
That may be true, but many users have other things running besides
your application. Avoiding to unnecessarily eat processor cycles
isn't just good because *your* app remains useable. If the movie I'm
watching in another window starts becoming jerky just because I click
inside my CAD drawing, something is definitely wrong.
I agree that, with a drawing engine as complex as Quartz, Graham's
approach of mathematically doing hit-testing will in most cases get
very complicated very quickly. But that doesn't mean you should
forsake all optimization. Mathematic hit testing will usually be
faster than drawing and testing a pixel, simply because (at least in
the ideal case) you "project" only the single pixel you are testing
for, instead of the whole shebang.
So, a good idea IMHO is to do approximate hit testing using
rectangles or sections of a complex shape that are guaranteed to be
larger rather than smaller, and then do precise hit testing only on
the remaining items, and one-by-one in front-to-back order.
Drawing all objects just because you want to account for
transparency is wasteful. Especially if whatever your user is
clicking at is the frontmost opque object...
Just my thoughts on the subject.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden