-
Notifications
You must be signed in to change notification settings - Fork 938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
25 FPS on iPad 3 #126
Comments
I'll need to investigate what has happened to performance. On device, we should be achieving 60fps without issue. |
I don't have an iPad 3 at home, but I ran some tests on older iPhones and didn's see anything unusual. I do need to track down this device. What version of iOS is it running? |
It's running iOS 8.4. The image cache isn't slow, UIKit is. I'm testing the performance on an iPad 3 because the iPad 3 historically has the worst graphics performance of any iOS device. Replacing the table view cell's call to
Note: I did change the demo app to have 5000 unique photos instead of 100, because 100 photos never exercised the cache's 400 image limit. |
@mallorypaine It looks like I am reproducing #82 with the demo app. The code I am running is here. Should the cache not have a overflow list for the extra images when there are more images requested than can fit in the cache? |
What are your exact steps to repro #82? |
I was scrolling down fast enough to get 400+ requests in-flight at the same time. I guess it depends on the device but it was easy with the iPad 3, which can only process a few images a second. |
I believe your PR addressed this. |
I'm running the Demo App on an iPad 3 and getting 25 FPS when scrolling up and down (20 FPS without #125). The app becomes CPU-bound once each cell is changing every frame. An iPad 3 does not have the CPU to create 100+
UIImage
s, assign them toUIImageView
s and commit the changes to Core Animation.A workaround I have on this branch is to wrap every image fetch in a
NSBlockOperation
. The operation guarantees that the app will get 60 FPS because it avoids returning all 100+ images in a single frame. This is most noticeable on an iPad 3, which can only perform ~7 image updates per frame.I feel that the cache should provide async and cancellable requests, by default, so that every use of the cache does not need to implement its own throttling. Regardless of the speed of the device, and no matter how amazing the cache, there is always a limit on the number of images that can be fetched in a single frame because each request takes a non-zero amount of time.
Thoughts?
I am happy to work on this, given a bit of guidance on the internal threading and the callback structure of the image cache.
The text was updated successfully, but these errors were encountered: