Re: Select a NSBezierPath
Re: Select a NSBezierPath
- Subject: Re: Select a NSBezierPath
- From: Graham Cox <email@hidden>
- Date: Tue, 21 Sep 2004 23:12:28 +1000
On 21 Sep 2004, at 10:13 pm, Robert Clair wrote:
It sounds simpler, but it's much slower.
When you draw a Bezier curve, you have to first compute the curve,
then
rasterize it into a buffer, then hit test that. The mathematical
approach involves only the first of these steps, and it can bail early
if a hit is found. The drawing step is the killer, dwarfing the time
the rest takes.
"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.
True enough, but then again the math approach is "fast enough" too.
Drawing *is* slow. But you're not going to draw too much. You're going
to keep a bounding
box for each object and test it against the bounding box of your pick
area
so that you don't bother Quartz with things that can't possibly be
picked. And while
I'm not privy to the internal workings of Quartz, I'm sure it makes a
reasonable effort not to
waste its time on things that are outside the view bounds. There's not
much pixel pushing.
Depending on the size of your pick area, we are probably talking about
less than 200 pixels.
I guess it depends on what sort of things you're drawing to some
extent. In my case it's many, many fairly narrow curves (it's not a
general purpose drawing app). If the curve width varies a lot or you
have a great variety of shapes, the drawing buffer solution might work
better. Plus you can cache things as needed and only draw when you have
to. I didn't say it wasn't a good way to do it, but the math way is
faster and simple to do too.
Also - I'm curious. How do you you handle wide lines ? What if the
user makes a curve
with a one inch line width ? (Or any width much larger than your
picking tolerance.) Do
you require them to click near the center ? What about filled shapes ?
If you have
a filled circle do you have to click near the edge ? (These can be
handled analytically, but
it is a *lot* of trouble.)
In this particular app these aspects are not relevant - all my lines
are more or less the same width - there is some variation but not huge.
My hit tolerance value is based off the width of the line (chicken and
egg? - not really, because it only starts to refine the hit once it's
established it's within the bounding box already), so it will hit test
these accurately enough for eyeballing a click on a curve. In practice
there are very few situations where it doesn't select the right thing,
and those situations (like a whole bunch right on top of one another or
very close) would probably be problematic for the draw buffer approach
too. I hit detect other types of shapes another way.
It might be worth retrying the draw buffer solution again for this app
- the last time I compared the two solutions was a considerable while
ago and that was before Quartz existed and the Mac had native bezier
support (which I'm sure has now been optimised as much as possible ;-)
Certainly the performance back then was miserable enough that the math
approach was significantly better. Things have probably changed, but
once bitten... I tend to stick with what I've used before that works.
Graham
_______________________________________________
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