Re: Where to noteHeightOfRowsWithIndexesChanged
Re: Where to noteHeightOfRowsWithIndexesChanged
- Subject: Re: Where to noteHeightOfRowsWithIndexesChanged
- From: Tony P <email@hidden>
- Date: Wed, 16 Jun 2010 16:17:47 +0100
Thanks for all the responses folks.
On 15 Jun 2010, at 7:22 pm, Corbin Dunn wrote:
Do the height calculations in the bounds change, and then call the
"noteHeight.." method all in the same run loop stack; that will
probably fix your problem.
Beautiful, works like a dream. Many, many thanks for that, you're a
superstar!
Even though it is fast, however, a table with 200,000 rows is
excessive. There is no way a user can realistically use all those
rows without some sort of filtering/searching. I would consider re-
doing your UI to have a "more results" button, akin to the Finder
spotlight search results.
It does have a search, and I would agree, but arbitrary browsing is
required (even from the search which just scrolls to the results).
Unfortunately it's a PC->Mac port and you'll have to drag me through
hot coals before I'll be happy with a Mac version that seems somehow
inferior to the PC version. It's an iPhone version next though, so
I'll definitely have to re-think the UI for that.
Thanks again,
Tony Pollard
On 15 Jun 2010, at 7:22 pm, Corbin Dunn wrote:
On Jun 15, 2010, at 10:55 AM, Jens Alfke wrote:
On Jun 15, 2010, at 10:51 AM, Jerry Krinock wrote:
I send noteHeightOfRowsWithIndexesChanged: after updating the
contents of the array controller to which a table is bound, but I
still see little artifacts sometimes. It's in a rarely-used
utility view so I've let it slide. But under the conditions you've
mentioned,
If you can reproduce this, please log a bug.
There are usually about 200,000 rows, so calculating the actual
height for all rows is not an option (since it takes about 19
seconds).
you may have exceeded the capabilities of NSTableView's variable
heights
I agree. Variable row heights were a late addition to NSTableView
(added in 10.3 or 10.4?) and I wouldn’t be surprised if they’re not
optimized for huge numbers of rows.
The table view is optimized for a huge number of rows -- the
implementation in 10.3-10.6 uses a sparse array of row heights, and
attempts to lump together equal row heights into a single bucket.
This makes it quite fast at computations. Having a lot of non-equal
row heights will be more expensive (there is no way around that) as
each rowRect computation needs to figure out where to be.
Even though it is fast, however, a table with 200,000 rows is
excessive. There is no way a user can realistically use all those
rows without some sort of filtering/searching. I would consider re-
doing your UI to have a "more results" button, akin to the Finder
spotlight search results.
With respect to:
The tableview has variable height rows, and because of a relatively
slow data source, resizing and user control of fonts, etc, I don't
know the row height in advance. I'm caching the row height, and
returning a single-line height if the row is not visible (and the
height is not yet known). If the row is visible I calculate the
actual height and return that (via the NSTableView heightOfRow
delegate).
This almost works, but I've not found a good place to put
noteHeightOfRowsWithIndexesChanged. I get either overlapping rows
or some blank rows during scroll. I've tried
NSViewBoundsDidChangeNotification. I've even tried putting it in
the heightOfRow delegate (which I know must be wrong), with some re-
entrancy control which has given the best results so far (but still
displays blank rows sometimes). There are usually about 200,000
rows, so calculating the actual height for all rows is not an
option (since it takes about 1
You need to always return the *same* height until you call
noteHeightOfRowsWithIndexesChanged. After calling that method, the
said indexes can return a new height. Not doing this will cause the
types of problems that you see, as the table may (or may not) cache
every row height, and expects the same result to be returned for the
same row every time (until it was told it changed).
Sending the node in some sort of bounds changed notification should
be fine -- the problem you are encountering is probably because you
are breaking the above rule mentioned. Do the height calculations in
the bounds change, and then call the "noteHeight.." method all in
the same run loop stack; that will probably fix your problem.
corbin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden