Re: NSTableView Highlighting, Speed, etc.
Re: NSTableView Highlighting, Speed, etc.
- Subject: Re: NSTableView Highlighting, Speed, etc.
- From: Brian Webster <email@hidden>
- Date: Sat, 18 Jan 2003 00:44:32 -0600
On Saturday, January 18, 2003, at 12:00 AM,
email@hidden wrote:
I have a table view (n rows x 2 columns), which doesn't lend itself to
text, so I am drawing each cell with a custom graphic (NSImage). I have
several questions...
1) I am filling the entire row with an NSImage, which apparently blocks
the table views highlighting. I would still like to use NSTableView's
highlighting, so what should I do? I either have to make the image
smaller or make parts of it transparent. Is there some way to apply the
highlighting on top of the image?
Having transparency for part of your image is probably the easiest way
to go about this. If you are reading in an image from a file, make
sure your file has an alpha channel; if you are drawing the image on
the fly, you can fill your image with [NSColor clearColor] before
drawing so that its background will be transparent.
2) This particular table view will generally have several hundred rows,
with a maximum of around 2,000 rows. The cell sizes are 38 x 23 (width
x height) for the 1st column and 805 x 23 for the 2nd column. I was
initially allocating a new NSImage for each cell and releasing it after
passing it off to the table view. I then switched to 2 reusable
NSImages, but I did not notice any appreciable difference in
performance. With allocating images, I didn't have to erase a reusable
image, so maybe it's a wash. Any thoughts on what might be better here?
If you're having performance problems, you might check to see if you
have scaling turned on in your image cells. If it is on, the table
view will have to scale your image every time you pass it back to be
drawn, which can cause quite a speed hit.
The default setup for a table view is to reuse a single cell for each
row as it is drawn, but you can also set it up to use different cells
for each row by subclassing NSTableColumn and overriding the
dataCellForRow: method. This way, you could store an image in each
cell and you wouldn't have to create or redraw the image each time,
which could speed things up. Of course the down side to this is that
it will take up quite a bit more memory, so it's a speed vs. memory
tradeoff.
3) With my table view (and others I've tried), It appears that the
vertical scroll bar's "thumb" has some sort of throttling mechanism. If
I move the thumb slowly, the table view keeps up with it nicely. As I
move it faster, there seems to be a distinct point where it gets jerky
and the table no longer smoothly keeps up with the movement. If I use
the scroll bar's arrows, it scrolls very fast, significantly faster
than it does by moving the thumb. Why does it seem like the thumb's
fastest smooth rate is slower than the up/down arrow's?
Scroll views do use an optimization (on by default) whereby any portion
of the view that is visible and will remain visible after scrolling is
copied to its new location instead of requesting for the contents to be
redrawn from scratch. So in your case, hitting the down arrow will
only cause a couple of rows to actually be redrawn, and everything else
will just have the old image copied up or down a certain number of
pixels. But if you drag the scroll knob fast enough, there may be no
portion of the view that can be copied over and the entire visible
portion has to be redrawn, making it move quite a bit slower.
--
Brian Webster
email@hidden
http://homepage.mac.com/bwebster
_______________________________________________
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.