Re: NSTableView Highlighting, Speed, etc.
Re: NSTableView Highlighting, Speed, etc.
- Subject: Re: NSTableView Highlighting, Speed, etc.
- From: Keith Renz <email@hidden>
- Date: Sat, 18 Jan 2003 12:54:48 -0500
Brian,
Thanks for the reply.
On Saturday, January 18, 2003, at 01:44 AM, Brian Webster wrote:
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.
I tried using
color = [NSColor clearColor];
[color set];
[path fill];
but it does not erase the old drawing on the image. I must use a color
with no transparency (such as whiteColor) to erase the old drawing and
then I can't make it transparent again using clearColor. How can I make
the image transparent again without allocating a new one? That would be
most helpful! I'd like to run a test to see which way's faster.
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.
I have scaling turned off and I create the images to exactly fill the
cells.
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.
I would have to redraw the images on the fly either way, so the bottom
line is do I want to pre-allocate or create on the fly ~500-2000
NSImageCells and their NSImages and use dataCellForRow: or 1000
NSImages and use tableView:objectValueForTableColumn:. I don't need
different cells for the different rows. They're always all
NSImageCells, and all the same size, so I think dataCellForRow: would
be unnecessary _unless_ it's faster, which I doubt. I'll play around
with all these ideas and see how it goes.
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.
Okay, I understand. It was basically the same in OS 9 -- it slid the
old image. If it slid it completely off the window, it had to do a
complete redraw. Except that in OS 9, you had the option to not erase
the exposed area, and since it was not double buffered, that made a
difference (unless you used copybits from an offscreen bitmap). I don't
know what's happening here since everything's double buffered. Maybe
the image changes above will improve the speed. Granted, it's
definitely not slow and it looks nice, but the same mechanics in OS 9
are faster, although I was using my "home built" table, which was
custom designed specifically for this purpose. I'd like to avoid that!
Keith
_______________________________________________
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.