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 protected]) 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]
