On Aug 8, 2008, at 8:54 AM, Graham Cox wrote:
Are you checking the view's -needsToDrawRect: when you actually
iterate through your rectangles? For a view like this it will be
essential to avoid drawing anything that doesn't need drawing - even
checking thousands of rects for intersection with the update area is
much faster than actually drawing the same rects.
And the flip-side of that is, are you ensuring that when an
individual rectangle is moved or its contents changed, you just
invalidate that rectangle and not the whole view?
These two together should sort out your framerate problems - the
screen shot is busy but it's not unreasonable - I wouldn't expect
1.2 fps even with this many rects as long as you are doing the two
key things above.
Dear Graham: Thank you for the reply. The way you worded the above
kind of snapped me out of a "thinking too much" situation that I must
have been in, because I scrapped my 2nd view idea and implemented the
above and now I'm at 12 fps which is fantastic for my one user :)
Throwing a backing layer at the problem isn't going to magically fix
it if there's a basic problem with drawing too much.
Ultimately it doesn't matter that everything is drawn in the same
view. It might make sense to break it down just to keep the code
sensible, but it won't automatically fix up drawing speed problems -
after all, you're blitting into the same pixel buffer whoever draws
them.
Thanks for this too. I was under the mistaken impression that I had to
make this separation in order to move forward.
You mention a background view - is that really a separate view, or
just a term you're using for your grid graphics?
In my original design, it was just a term, but I was starting to split
it into its own view due to my misunderstanding of what I had to do.
Either way, if you decide to invalidate the whole view at any point
you are going to stuff yourself. There's rarely a reason to ever
invalidate a whole view (except for maybe the first time it's drawn,
and that's handled by Cocoa, not you). The grid doesn't need to be
repainted in its entirety for every change for example - again, just
draw the little piece revealed by the update event. Doing that is
actually less work for you to code than not doing it - when
drawRect: is called it's already clipped to the update region, so
just repaint the grid - pixels outside the clip region are not drawn
so do not impose a drag on the drawing speed (cache the grid path
also to avoid recalculating it every time). The key is never to call
setNeedsDisplay:, but ALWAYS use setNeedsDisplayInRect:. Search your
code for uses of -setNeedsDisplay: and change it.
Perfect. Even though I had read the view guide several times, I didn't
have it solidified in my mind that when you use -
setNeedsDisplayInRect: that Quartz (if that is the correct term here)
clips any drawing that occurs outside of the collection of dirty
rects. Now I can see it in action.
I am also testing each of my rects now to see if it is within the area
needing drawing (I am using -needsToDrawRect:). All the rest of the
elements I just go ahead and draw since they always drew very fast
anyway.
Incidentally, this looks like an ideal project to use my own DrawKit
framework for, if you'll permit me the shameless plug. I just tried
drawing about 460 small rects with text in them similar to yours and
on my lowly MacBook 1st gen I get no framerate problems moving them
around. Dragging a semi-transparent selection rect over them is a
little stuttery, but usable. I also have a full-view grid behind
everything (much more complex than yours too) so it's doable. I'm
not doing any CALayer backing (incidentally on 10.4 you have CGLayer
which provides similar functionality though much more basic). If you
want to look at DrawKit, you can d/l it here: http://apptree.net/drawkitmain.htm
. Even if you don't want to use the framework you may find the code
worth a look to see how I draw stuff quickly without any tricky stuff.
I have downloaded your framework and I am amazed at how much is in
there and how neatly coded it looks! I think for this project it would
take me too long to learn enough about your framework and to implement
it into my (currently working) app. My user is going to be thrilled
with 12fps and for that I am very thankful to you and the others who
helped me before.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
