Re: Quartz/memory benchmarks...
Re: Quartz/memory benchmarks...
- Subject: Re: Quartz/memory benchmarks...
- From: Kyle Hammond <email@hidden>
- Date: Thu, 27 Jun 2002 18:43:54 -0500
On Thursday, June 27, 2002, at 05:18 PM, Allan Odgaard wrote:
Users aren't going to be able to do what your programmatic scrolling
is doing.
Actually, I wanted to programatically do the steps in between the
scroll factor, so that one can scroll while reading a document without
loosing the focus -- unfortunately this is impossible on the Mac,
because the smooth ease in/out won't be realtime and so just look
irritating... maybe I should just go back to my Amiga until Quartz
Extreme is released ;-)
Maybe. :) It wasn't clear from your post what your intent was. For
most uses (not all, but most) NSTableView works acceptably well. In
other cases it's useful to make a custom NSView subclass that draws a
table itself since the custom view can do specific optimizations that
the general NSTableView cannot (you know you have strings, or images, or
whatever; you know what attributes you want to draw with; etc.).
If you're interested in some fairly obvious (and possibly mind numbing)
results summarized below, read on. For those who don't give a damn,
stop reading now. These numbers come out of Sampler app while looking
at the ScrollBenchmark application scrolling in "Sinus movement".
For the default window size when the application starts up, Sampler is
showing that roughly 42% of the time is spent in refreshing the window
onto the screen and 34% is spent on the actual scrolling (code called
from the timer firing). The other 24% of the time is spent in mach_msg,
with a few thousandths of the time spent in various other low level
calls.
For the window running at full screen (which for me is 1152 x 768).
Sampler is also showing 42% of the time in refreshing the window onto
the screen, 35% of the time handling the scrolling and 23% of the time
spent in mach_msg.
The interesting thing to me is that the % time numbers do not change for
screen size. That means the bigger the window, the slower it goes and
the smaller the window the faster it goes. Period. Pretty obvious, but
still interesting to note.
However, looking at just the scrolling portion of the activity, Sampler
shows that for the default window size, drawing the newly exposed parts
of the table view occupy 61% of the time and copying the old part of the
view to the new position takes 26% of the time. The other 3% of the
time is spent mostly in -lockFocus (presumably to draw each newly
exposed cell of the table).
For the full screen window, the scrolling portion of the activity shows
21% of the time redrawing newly exposed parts of the table and a
whopping 77% of the time copying the old part of the view to the new
position. The other 2% of the time is spent mostly in
-setNeedsDisplayInRect, which is somewhat surprising to me. It seems to
take a relatively long time to get the display rectangles merged
together in this case.
These numbers seem to show the speed, or lack thereof, of the copying
routines is the bottleneck at large window sizes. Probably obvious to
anyone who has bothered to read this far, but it's always nice to verify
that it's the copying routines and not the speed of drawing strings
that's the slowdown. In fact, making a subclass of NSTableView and just
having a blank -drawRow:clipRect: method shows approximately the same
relative numbers as above.
Hopefully, with Quartz Extreme, the copying will be using more and/or
faster hardware acceleration. Then the bottleneck will turn into
drawing the strings, which would be a great thing for large window
scrolling.
I hope someone found this useful, because I just shot my afternoon
goofing around on this for no particular purpose. :-)
Enjoy,
Kyle
---------------------
Kyle Hammond
email@hidden
http://www.CodeBlazer.com/ - multimedia software solutions
http://www.isd.net/dsl03002/ - my personal home page
http://cocoabudget.home.att.net/ - Budget for MacOS X home page
_______________________________________________
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.