views:

875

answers:

3

I'm using part of the Three20 library in a project. Specifically, a view that is essentially a table view with images going 4-wide across each cell to mimic the iPhone's photo app thumbnail view.

I've noticed that the behavior is for each cell to be dequeued as soon as the bottom of the cell reaches the bottom of the navigation bar (which is translucent so we can actually see it disappearing). The problem this presents is that each time a cell is dequeued and then brought back into view it reloads the images, which causes the scrolling to become very jittery at anything beyond a slow scroll of the table. I know the cells are reused to minimize memory usage, but is it possible to prevent the cells from being dequeued? Or re-define the "boundary" for when they're prepped for reuse to create a larger buffer so they only disappear when they're a certain number of rows off screen?

+1  A: 

You have dequeuing backwards. UITableView doesn't dequeue. You do that when you call -dequeueResusableCellWithIdentifier:. To "dequeue" doesn't mean "to release." It means "pull off the queue of cached no-longer-in-use reusable cells." It's called "dequeuing" because it's a FIFO queue of cells, and you are pulling the first one off.

If scrolling is slow you need to improve your drawing speed, and perhaps you need to return cells faster when UITableView asks for them. The system of dequeuing reusable cells isn't to save memory (it actually costs memory); it's to improve performance. You don't want to circumvent it; this is exactly the situation it's there to help fix.

So, how are you drawing these cells, and how are you configuring them when UITableView asks for one? That's where we're going to find your performance improvement.

Rob Napier
Thanks for the clarification. I don't entirely understand the library and it's not well documented/there isn't a lot of commenting in the code. [This](http://github.com/joehewitt/three20/tree/b78944872623673b1329688fd59a5708f048bef8/src) is the library and [this](http://github.com/joehewitt/three20/blob/b78944872623673b1329688fd59a5708f048bef8/src/TTThumbsViewController.m) is the class itself. I'm trying to look through the imported classes to see where the actual configuring is taking place.
shoreline
A: 

I believe you want to change the table view frame to include your navigation bar region.

[self.tableView setFrame:GCRectMake(0,0,320,480)];

You should keep in mind that this may cause some other issues as that area will be counted as viewable area and you won't be able to scroll the first cell out from under your translucent navigation bar. To work around this you may need to also set your tableView.tableHeaderView to an empty UIView that corresponds to the height of the UINavigationBar

(in theory you could have the same problems with a UITabBar at the bottom of your view).

Jehiah
How is resizing the tableView helping here?
Rob Napier
because the frame used for calculating when a table cell is viewable/not viewable can sometimes have the wrong value. IE: it does not include under the transparent navigation bar because a navigation bar is not normally transparent and normally it's ok for table cells to be removed from view at that point in time.
Jehiah
A: 

You could try putting your images into an NSMutableDictionary. In the place where you build your cell, check if the image you want is already stored. If it is, use that copy, if not load it from wherever you're getting the images from originally and place it in the dictionary. I think I used an NSMutableDictionary with the image identifier as the key and the image as the value to do this and it sped up the table scrolling.

You might want to unload the NSMutableDictionary if you get a memory warning.

Your problem may just be that you're loading images over the network, which makes scrolling jerky. Check here for a solution to that.

http://stackoverflow.com/questions/932859/preloading-images-from-url-in-tableviewcell/

nevan
The thumbs are being loaded off the app's document directory. But I've noticed that the behavior of the Facebook app, which is what the thumb view is based off, creates the cell and then adds the thumb as it's retrieved. This method doesn't have the same stutter.
shoreline
Are you resizing your thumbs or masking them? If there's any extra processing before you load the images into the cell, that will delay the cell being displayed. If that's the case, keeping the processed images in memory will speed things up.
nevan
The thumbs are resized; they're created when the files are written to the documents directory. I did try playing with reducing the file size further, both by changing the thumb dimensions and the image quality when it's written, but the decrease in image quality wasn't worth the performance increase. I've noticed that the facebook app doesn't actually "erase" the cell itself when it goes off screen, only the thumb is released and then redrawn one at a time when the cells come back into view. I'm not sure why Three20 differs, unless the creator changed something.
shoreline
If the thumbs are resized before they're saved, it can't be causing a slowdown.I checked out the facebook app, with a page of 100 photos. It's loading the images in the background, but not storing them in memory. Can you ever see a row with empty spaces where the images should be? Do those spaces then get filled in with images? If you can see this, your app is loading images in a background thread. Loading on the main thread will cause jitters.Are your images saved as squares in the documents folder or are they being masked (or cropped) on the fly just before they're loaded into the cells?
nevan
The cells actually disappear. They don't stay, although empty, like the facebook ones do when they're off screen. The cells and the images are both redrawn as soon as they are brought back into view. I feel like this has something to do with the library being designed to load remote images. There's a catalog app that demonstrates the same behavior the facebook app exhibits, and when I use the exact same methods but just load local images, the cells disappear and the images are gone too.
shoreline