views:

1232

answers:

3

I have a tableview that displays a lot of images in the cells, and i am not quit happy about the scroll performance. My tableview is something like the photo app on the iphone. Does anybody knows why the iphone foto app scrolls so damn fast as if their's nothing on the screen.

And does anybody has some tips/tricks to increase my performance/scrolling speed?

A: 

Great scrolling performance results have been reported by subclassing UITableViewCell and drawing the contents of each cell directly. See the accepted answer for this question for more details and links to code samples.

Prairiedogg
The discussion in the blog you link to isn't appropriate for this question - it's talking about compositing performance in the iphone and recommending you take care of this by implementing your own drawing code to use full opacity. This question likely isn't suffering from that problem. Typically unless you have good reason to, you shouldn't be extending the cell itself! It's much better to add to the contentView and set the backgroundView so the table animations are handled properly.
groundhog
A: 

The problem here is memory, you are loading too many high resolution pictures at once, the foto app does not use a tableview it uses a scroll view and it only loads a max of 3 pictures at a time , so memory is not a concern, if u are trying to do something similar to the foto app use a scroll view

Daniel
+2  A: 

You should precache your images and not do it lazily. As you scroll your table the UITableViewDataSource:cellForRowAtIndexPath: method is called, and if you're loading your images in there then you'll see it requesting your cell contents as your scroll, creating latency in your application. Try putting making your cellForRowAtIndexPath: something like this:

NSDate *date = [NSDate date];
... your cell loading code ...
NSLog( @"Elapsed time to generate cell %.2d", [date timeIntervalSinceNow] );

You'll see how long you're spending for getting each cell.

To get around this, you can be as complex as you need to - if you have a lot of images, you're going to have to be more and more clever. You can do paged loading, where you keep track of the last cell requested's NSIndexPath, and determine if the scroll is going up or down and use +NSImage:imageNamed: to fetch at once some page worth of images forward (ie, 5 images forward of your current position), or whatever works out for you (taking advantage of the fact that people have to return their finger down to the bottom of the table to swipe again, and so the consumption of table elements has pauses - you can make your page size large enough to fill a swipe). This is probably still not great, though, because you'll just be suffering all your impact at once instead of a jittery load for every cell.

You can return control to the UI rapidly and allow the system to schedule your prefetched page of images using NSRunLoop:performSelector:target:argument:order:mode: off the main runloop using NSImage:imageNamed:, and then when the cell is requested if you're fetching far enough ahead it'll be available to display.

You need to be painfully aware of memory concerns though. If you're finding this to be an issue, use NSImage:initWithContentsOfFile:, which will clean up image caches in low memory situations. Depending on the strategy used by the cache invalidation algorithm these situations may cause a "stutter" as you purge caches and have to reload your invalidated prefetches.

groundhog
I dont have to use a scrollview that daniel suggested? Is their a difference?
Ton
No - in fact daniels comment is a bit odd because my view of the photo app it loads an entire grid of photos across the screen, four wide. That's much harder - but what they are doing is keeping a thumbnail and using those. It still isn't totally smooth if you swipe quickly it stutters a bit. The table actually is easier because it let's you know when to expect to need to get more images.
groundhog
Thanks for your explanation!
Ton