Re: Subclassing NSTableView
Re: Subclassing NSTableView
- Subject: Re: Subclassing NSTableView
- From: Rainer Brockerhoff <email@hidden>
- Date: Fri, 26 Oct 2001 12:34:50 -0200
Date: Fri, 26 Oct 2001 02:12:43 +0200
From: Norbert Heger <email@hidden>
Drew McCormack <email@hidden> wrote:
I've been trying to subclass NSTableView so that I can have rows of
> different heights...
>
For performance and efficiency reasons NSTableView is designed to load the
data displayed in the visible rows lazily (on demand). Therefore NSTableView
must be able to determine the range of rows that have do be displayed at a
given scroller position. If the rows do not have the same heights it would
be necessary to know the heights of ALL rows in advance, in order to
calculate the visible range of rows.
Just imagine a table of 50.000 rows, the vertical scroller somewhere in the
middle. Given the current design (assuming that all rows do have the same
height), this is no problem at all. With different row heights this would be
a huge performance problem.
I haven't needed to use NSTableView yet, but for past (PPC on
Classic) applications I did a PowerPlant equivalent which ran with
250,000 variable-sized rows (a dictionary word list) with individual
size settings (including 0) with no performance penalty at all.
A similar implementation for the Palm Pilot ran OK with 1,000 rows.
Granted this was hand-optimized. I suppose that it would be doable in
a Cocoa implementation if one avoided any Objective-C runtime calls
in the inner loop :-)
--
Rainer Brockerhoff <email@hidden>
Belo Horizonte, Brazil
"Originality is the art of concealing your sources."
http://www.brockerhoff.net/ (updated Oct. 2001)
--
Rainer Brockerhoff <email@hidden>
Belo Horizonte, Brazil
"Originality is the art of concealing your sources."
http://www.brockerhoff.net/ (updated Oct. 2001)