-
-
Notifications
You must be signed in to change notification settings - Fork 6k
Commit
…ction (read-on to understand why) I finally found the reason behind the download not started while UITableView is manipulated: the default NSURLConnection runloop mode. Its default mode is NSEventTrackingRunLoopMode which is interrupted by UI events. Changing default NSURLConnection runloop mode to NSRunLoopCommonModes just fix this good old responsiveness issue. I thus decided to replace the current NSOperation based implementation by this finding, as NSOperation is far more expensive than simple async connections. Additionally, moving aways from NSOperation here fix an odd lagging issue with iOS 4, an issue I can't explain at the moment. Note that `SDWebImageDownloader`'s `setMaxConcurrentDownloads:` method is now a no-op as I didn't implemented the NSOperation queuing system with async connections. I don't think it still necessary as thread-less async connectaions are very lightweight. If you think there is a real need of this, I may reconsider and implement it in the future. In the meantime, this method does nothing and its usage is declared as deprecated.
- Loading branch information
There are no files selected for viewing
4 comments
on commit e0e3696
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that
SDWebImageDownloader
'ssetMaxConcurrentDownloads:
method is now a no-op as I didn't implemented the NSOperation queuing system with async connections. I don't think it still necessary as thread-less async connections are very lightweight.
I think 'setMaxConcurrentDownloads' is quite important - my experience suggests if you are on a 3G or slower connection, starting more than 2 or 3 downloads results in poorer performance as the connection gets over saturated. Users are generally a bit happier seeing images appearing gradually rather than all the images suddenly showing up after a long time with nothing.
(This is a great class btw, really helped me get my app going quickly!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fact is connections are cancelled when download is not completed while being reused in UITableView. You shouldn't have more connections than cells visible on screen though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with jogu.
Get an iphone 3G (or iphone 2)..and you can make sure that just more than 2 or 3 downloads results in bad performances.
The UI almost freezes til the downloads are finished..even with a WiFi connection.
You shouldn't have more connections than cells visible on screen (because of reusing) : that's a good point. But i think you often get more than 3 cells visible on a screen..
Should we still consider iphone 3G (and 2) ?
I also wonder what happen if you switch between UITableViews of a UITabBarController, i think downloads continue while you're not showing their respective UITableView. Should we cancel these downloads ?
Anyway, thank you for this class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm testing the lib with a 3G and I don't experience this lagging issue. About your question on the switch between tabs, I guess when the view will disappear, chances are that the cell will be unloaded and thus corresponding downloads should be cancelled. This really depends on the app actually.
Anyway, I would be happy to merge a patch implementing a simple and effectif concurrent connections limiter though ;)
hi, Could you talk me why don't use synchronized here ?