Keep track of in-progress tasks; avoid crash with CGSizeZero #6
Conversation
… avoid inserting nil image into cache. A nil image can result from someone sending CGSizeZero to the method. I think calling completion with the nil image without crashing is a good expected result for that case.
|
There are a couple of pottentially thread-unsafe things in that code, which I'll look over, but I think it looks good in general. I also think it makes sense, and it's a pretty common use-case (scrolling up and down on a table for exaple). I'm wondering if it makes sense to implement this this way or if I should switch to the NSOperation approach (#1), in which case the implementation would be slightly different (probably using operation dependencies). I'll look into all this as soon as I can (busy week). In the mean time, what are your thoughts? |
|
Yeah, the NSMutableDictionary calls should be wrapped in NSLock. I think this optimization can wait for the merge of the NSOperation feature branch if you decide to go forward with it. My use case gains a lot of benefit from the NSOperation approach. |
…t. Also, avoid inserting nil image into cache." This reverts commit f9be0bf.
|
I'll open another pull request for the in-progress feature later, after switch to NSOperations (if you decide to), in a feature branch instead of from my master (oops) |
2 participants
Keep track of in-progress render tasks to avoid duplication of effort for identical cache keys. This optimizes for cases where multiple events for the same cache key might be generated in quick succession before the first render is finished and written to the cache.
A nil image can result from someone sending in CGSizeZero. I think calling completion with the nil image without crashing is a good expected result for that case.