NSView and performance drawing again. A Result!
NSView and performance drawing again. A Result!
- Subject: NSView and performance drawing again. A Result!
- From: Paul Fox <email@hidden>
- Date: Thu, 11 Jul 2002 12:02:09 +0000
After a lot of head bashing trying to see where the performance
probs were with drawing text in an NSView (not NSView related per se, but
just using [NSString drawAtPoint:..]).
I experimented with NSLayoutManager and friends and had no joy. I was
certainly confused trying to get my head around text storage and the layout
objects. I gave up on that.
I tried using the CG functions and got very close but something seemed
to be missing to let me get this job done. Performance was bad
because I had to keep setting the font and couldnt figure out how
to create a 'platform font' pointer (seemed like a lot of hard work).
I tried investigating the ATSU drawing code - and came very close on
this - performance about 4+ times faster than [NSString] drawing - but
kept hitting brickwalls and curious API failures, and couldnt figure out
what was wrong. It seemed ever so complex.
I then stumbled on the old MacOS QuickDraw routines and wow! They are
fast babies - at least 10x faster than [NSString] (up to 20x faster
with decent application optimisation) and my app now screams. The
API was nice and simple and exactly what I expected to see in a Mac -
similar to X and Win32, and the docs on the Apple website (dating
back years) gave me a grounding in understanding some of the
peculiarities in Cocoa (terminology, font spacing etc).
My text drawing is now significantly faster than it was before - auto-repeating
on the keyboard indicates the screen updates can keep up, and although
its not as fast as a slower windows machine, it is acceptable. I think
I have hit a barrier in terms of performance and cannot go any further
but nor do I think I need to worry about that too much anyhow.
So I just pass on my results to let people know that things can be much
quicker. I am still not sure why Cocoa is so slow - I believe its because
the whole NSView/NSLayoutManager/etc charade means that you should
donate all your text strings to the Cocoa objects and let them do the
drawing. Which is fine, unless you have a 1GB file to look at and then
I suspect it would fall over.
Trying to dynamically update a view with your own text storage means
there are huge bottlenecks in the way Cocoa does things.
If you have a static view of text, e.g. like in a text editor where
you just type a bit and the system can keep up - then fine. But this
app lets you do things (like Alt-N to switch to the next file) which
will force a complete screen redraw (similar to PgUp/PgDn but the
whole text storage buffer now changes). So Cocoa has a bottleneck trying
to get the data into the system. Once there it may be ok. But it wasnt
for me.
I must admit that Apple have done a good job of providing 5 ways
to draw (I think there are 6 - there was one last mechanism I hadnt
tried) and they all interact quite happily, from the QuickDraw, Carbon,
Cocoa, foundation, ATS etc.
If anyone wants to know more about what I have done or why I will be
pleased to share things. I did find some bugs in my code which may have
made things worse than they really were, but I am glad I have
got this far. Just need to fix the new bugs and I can go forwards.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.