Re: behind the scenes of -drawInRect:
Re: behind the scenes of -drawInRect:
- Subject: Re: behind the scenes of -drawInRect:
- From: Scott Ellsworth <email@hidden>
- Date: Wed, 31 May 2006 14:10:29 -0700
On May 26, 2006, at 4:35 PM, Joshua Scott Emmons wrote:
If so this will be the second time in as many months I've been
bitten by not knowing what some shortcut-method was a shortcut for!
Is there a way I should have been able to intuit what -drawInRect:
was doing behind the scenes from docs/common sense? If not, maybe
I'll file a documentation enhancement request to have that fleshed
out a little, unless you think that's frivolous.
I have been filing those as I came across them. To me, one of the
bigger weaknesses of the Cocoa docs lie in knowing the tradeoffs, and
one of the biggest recent improvements has been the Cocoa Drawing
Guide (and its ilk).
As a developer, it is very convenient to know that [[NSBezierPath
bezierPathWithOvalInRect] fill] takes twenty percent longer than
getting the bezier path once, and filling. A cached NSImage bitted
into a rect can get five times the performance, while a CGLayer can
get ten times the performance of calling [[NSBezierPath
bezierPathWithOvalInRect] fill] a zillion times.
The Cocoa Drawing Guide now addresses some of this, but it lacks
information on what payoff a developer should expect for techniques
more advanced than the most basic. I believe that is not an
accident, as it is video card and processor dependent, but I rather
wish it had more 'what you should expect' sections. After all, if I
know that the very best performance that I can expect is only ten
times better than what the simple one line of code gives me, then I
know that I need to rethink if I am getting 0.1fps, and when it is
worth going down that road.
I would also like to see some hard numbers attached to bezier path
complexity. It is clear that a bezier path with a hundred thousand
items in it will be glacial, but will it be glacial compared to a
hundred thousand separate paths? The app to test that is not hard,
but I have not spent the afternoon writing something that gives good,
reliable numbers.
This is not a completely vapor question - hard numbers and cutoffs
let developers know where to concentrate design effort up front.
Premature optimization is evil, but designing for the problem size
you expect can save lots of work down the road. I have an app that
draws between 3 and 375 nonoverlapping NSViews on the screen. I
could turn it into one big view, with 375 cell-equivalents, but that
would be enough work that I do not want to do so unless the payoff is
a good factor of two or more. Knowing that a hundred, or a thousand,
or ten thousand NSViews on the screen is a problem lets me know
whether I should expect problems, and should design accordingly.
(NB, on an MBP 17, 375 of these views is no problem at all.)
I also found the Core Data performance tips useful. Again, a few
hard numbers might be nice, like 'expect to commit only ten TPS, but
expect that committing tenK objects should not take long', but again,
that is hardware dependent.
Areas without a guide like that, though, are complete terra incognita
for a developer just designing an app.
Scott
_______________________________________________
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