* 'master' of https://github.com/rs/SDWebImage:
Update the comments and a little enhancement for FLAnimatedImageView Category
Use a dispatch semaphore to keep thread safe for downloader because it need the hold cancel and add procedure be thread-safe
Add the current image/alternateImage url for NSButton category. A little code refactoring
Update macOS demo to add a clear cache button using NSButton category
Fix that reset alternateImage cancel the image load operation for NSButton+WebCache
Add WebCache category for NSButton on macOS
A little enhancement to avoid block capture the heap object
Use a internal method to avoid thread-safe issue for file manager. Remove that checkIOQueue and add sync version exist API
Add the image transition argument for all UIView+WebCache, make this easy for user to do some fade transition. It also reuse the current setImageBlock and make it easy to customize
# Conflicts:
# SDWebImage.xcodeproj/project.pbxproj
# SDWebImage/SDImageCache.h
# SDWebImage/SDImageCache.m
# SDWebImage/UIView+WebCache.h
# SDWebImage/UIView+WebCache.m
# WebImage/SDWebImage.h
* Refactor code. Move the C global function to a new SDWebImageCoderHelper class.
1. Create two method for animated image parse. Provide the way to allow animates on macOS
2. Create a new class called SDWebImageFrame to allow abstract usage for animated image
3. Fix EXIF orientation method will crash on iOS 7 because it’s a iOS 8 above API
* Change sd_imageLoopCount to retrieve GIF loop count for NSImage on macOS
* Adopt the refactor code, change our build-in coder with that coder helper method to reduce complexity
* Update the demo project on macOS to show animated WebP
- open the decoding/encoding procedures to the users
- switch from hardcoded decoding/encoding to pluginable decoders/encoders (builtin + user created)
- `SDWebImageCodersManager` is a singleton holding an array of `SDImageCoder` (protocol). Even though a singleton is not necesarily a good pattern, in this case it eliminates dealing with passing this array around
- uses a priority queue behind scenes, which means the latest added coders have priority.
- the priority is crucial when encoding/decoding something, we go through the list and ask each coder if they can handle the current data (see `canDecodeFromData:`, `canEncodeToFormat:`, `canIncrementallyDecodeFromData:`)
- each coder must conform to this protocol `SDImageCoder` describing all the required behavior for a coder
- we provide 3 built-in coders: `SDWebImageImageIOCoder` (for JPEG, PNG, TIFF), `SDWebImageGIFCoder` (for GIF), `SDWebImageWebPCoder` (for WebP and animated WebP)
- the user of SDWebImage can create custom coders by conforming to `SDImageCoder` and adding the coders to `SDWebImageCodersManager`. See `addCoder:` or `removeCoder:` or `coders` getter to get the array
- in order to preserve backwards compatibility, the UIImage categories were preserved, calling the new coders APIs described above