Re: Profound UITableView rendering-performance problem, but only at certain positions?
Re: Profound UITableView rendering-performance problem, but only at certain positions?
- Subject: Re: Profound UITableView rendering-performance problem, but only at certain positions?
- From: Luke Hiesterman <email@hidden>
- Date: Tue, 24 Jul 2012 00:02:43 +0000
- Thread-topic: Profound UITableView rendering-performance problem, but only at certain positions?
On Jul 23, 2012, at 4:34 PM, Gavin Stokes wrote:
Though probably off topic, this is unnecessary work. If you just want to change where your arrow is pointing, you should reach into the cells and change the position of the arrow - you shouldn't be doing a reload for that. Think something more like for (UITableViewCell* cell in [tableView visibleCells]) {cell.thumbImageView.transform = TRANSFORM_CALCULATION;}
Thanks. I thought about doing this, but I'd end up doing the same things that reloading the cells is (minus one short line of text). The position of the arrow depends on data specific to each row; each row has an angle to a different target, which depends on the user's current position. So every row's angle has to be calculated independently; it's not just an offset that changes with heading. I could theoretically save some of the work if the user hasn't moved, but there's only a maximum of four rows involved.
I meant you're putting more load on the system by doing this, not necessarily that you, the developer, are doing more work. Reaching inside the cells and changing something requires far less processing than issuing a reload which, at a minimum, must create/dequeue new cells.
Luke
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden