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: Fritz Anderson <email@hidden>
- Date: Mon, 23 Jul 2012 10:16:28 -0500
I think the first problem you should concentrate on should be the multiply-overlaid drawings. It's hard to tell what's going on unless you share some code, or at least your design, so I can only ask general questions.
I assume you're using the UIAccelerometer delegate method to receive your rotation events. How are you triggering redraws?
How do you do the redraws? In particular, are you doing CG drawing directly in your delegate method, or are you using UIKit-gated drawing calls like -drawRect:? It's hard (I don't know if it's possible) to get in-line drawing right. Further, the drawRect: mechanism does your event coalescing for you, so you wouldn't have to worry about drawing code overlapping.
Can you ask the UITableView for the visible cells and send them -setNeedsDisplay, rather than having the table reload everything?
If it turns out that the speed of drawing the arrows is the issue, how are you drawing? Images? Core Animation? Core Graphics? UIBezierPath (are you caching the paths)? How do you handle rotation (that is, where and how do you apply a rotation transform to your drawing)?
Have you watched your drawing code with the Time Profiler instrument?
— F
On 22 Jul 2012, at 11:45 PM, Gavin Stokes wrote:
> Sometimes these work fine. But other times, the rendering is extremely
> slow, with many overlapping images appearing before they're erased. Even
> the labels in the cells are drawn offset and overlapping, although the
> table's not in motion. In the video here, you can see numerous arrow
> images being drawn before being erased. And in the middle of the third
> second of video, note the cell image flying up from the bottom of the
> screen and settling in the top row!
>
> http://www.youtube.com/watch?v=wL2EYAro-oM&feature=youtu.be
>
> Then if I scroll the table (keeping the same number of rows visible), the
> problem often mysteriously disappears.
>
> My theory is that the drawing performance suffers when the table is
> scrolled to particular pixel offsets. So I'm logging the UITableView's
> contentOffset, but that's always zero. Does anyone know how I can
> determine how far the tableview is scrolled? Or does anyone have another
> theory? I don't think there's a fundamental problem because again, the
> updates work fine in some table positions.
--
Fritz Anderson -- Xcode 4 Unleashed: Now in stores! -- <http://x4u.manoverboard.org/>
_______________________________________________
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