* Add support for retrying and reduce default timeout.
* Return HTTP error codes >= 400. Don't retry when failure is sure to occur again.
* Add missing nullability
* Use NSInteger
* Add support for varying pixel lengths.
On some devices the pixel length returned from CGImageCreate
sadly isn't 4 bytes per pixel.
Might be a good idea to support differing lengths.
Encoding this into the format would be a good
thing for sure.
Anyway, that's what this does.
* Add in methods for reading out bitsPerPixel too.
In order to avoid blocking on the main thread, PINRemoteImage creates
a UUID but does not immediately start a task instead putting it on an
operation queue. This means that a client can request cancelation for
a UUID before its task is created.
Previously, we attempted to handle this by maintaining a set of canceled
UUIDs. This was being done incorrectly however. The logic was to check if,
before creating a task, a UUID was in canceledTasks. If it was, don't
create the task. If it wasn't clear out the canceledTasks list. This
example illustrates why that was erroneous:
1. Request starting a task with UUID #1
2. Request starting a task with UUID #2
3. Request canceling UUID #2
4. Task creation starts for UUID #1
5. UUID one is not in canceledTasks so it is cleared
6. Task creation starts for UUID #2, it is not in canceledTasks
so the task is created and is not canceled.
This patch changes canceledTasks to a weak hash table and removes
the line which cleared out canceledTasks. As long as there are blocks
(for task creation) referencing the UUID, they will not be removed
from canceledTasks. When no one is referencing the UUIDs any longer,
they will be cleared out.
* Fix runaway NSData
Previously we were generating all the frames of the GIF and dispatching
to write the data to the disk. This presents a problem if the disk backs
up though and it can end up with theoretically every frame in memory. Instead,
generate a frame and write it one frame at a time. Slower, but prevents
this runaway memory situation.
* Early return on error, thans @rahul-malik & @timonus!
* Have PINProgressiveImage pass back the quality of the current progressive image
* fix
* Check for nil for imageProgress pointer
* Rename some variables
* Rename a bunch of things
* Update comment
* Modify estimatedRemainingTimeThreshhold behavior to match documentation
* Update documentation on maxProgressiveRenderSize property
* Update the behavior, not the docs
First, prevents a memory leak if users reference self in their PINAnimatedImage completions.
Second, this deletes decoded files when there are no more references to an animated image.
Previously we deleted on app open and exit.
I wasn't going to do this in case you closed a GIF and then reopened, but the more I
thought about it the cost is too high: A user can see their disk size balloon if they view
a bunch of GIFs and then check usage. They could also fill up their space enough while using
the app by viewing GIF after GIF that instability could result.
