Load performance pains

[RSully]

See issue #8 starting at this comment: https://github.com/RSully/RSColorPicker/issues/8#issuecomment-17669493

-genBitmap is slow and causes the color picker to block the main thread during each initialization.

---

Prior discussion:

@simonbs:

I'm sorry for jumping into the discussion like this but I'm very interested in hearing if anyone have figured out a way to improve the performance when loading the color picker? It gives me a very bad performance on my iPhone 5 so when pushing a view which contains the control onto my navigation stack, it does so without any animation. However, it seems that when the control has been loaded, the performance is really great.

@stuartjmoore:

I'm guessing the load slowdown is due to the loops and calculations in genBitmap. There's no need to generate a gradient background every single time (since the color wheel will likely never resize), so I'm to experiment with a static background from a screenshot.

[RSully]

My comment from prior discussion

---

I've created a branch for testing push/pop of the color picker within a UINavigationController

git fetch
git checkout enhance-nav_controller

~~Branch: https://github.com/RSully/RSColorPicker/tree/enhance-nav_controller Comparison: https://github.com/RSully/RSColorPicker/compare/master...enhance-nav_controller~~

This has been merged into #26

This has been merged into master

---

@stuartjmoore I agree the issue is likely generating the initial bitmap. I am still interested in keeping it resizable (though I'm not sure how often that would actually be used - right now probably never considering how slow it would be).

Time profiler:

Each of those purple spikes is pushing another view controller.

---

A few ideas are going through my head:

• Generate the bitmap off of the main thread (GCD comes to mind)
• Cache the bitmap on each init based on the size

Combining these ideas yields an interesting approach. Perhaps you would call something like this when the app launches:

[RSColorPickerView prepareForSize:CGSizeMake(256.0, 256.0)];

This could generate that bitmap in the background and then whenever initialized with that size loading would be near-instant.

The downside of course is that these bitmaps would sit in RAM even if the user never needs a color picker.

---

Edit:

Another time profiler without "Show Obj-C Only":

[RSully]

I've created #28 after someone mentioned the Accelerate.framework to me. This might be the first step in solving these performance issues. If anyone has any experience or input on which direction to head in, let me know.

[RSully]

Wow, well it has been a long week. Besides getting my feet wet with CocoaPods and merging in some contributions, #28 is a huge overhaul.

A brief rundown (work in progress of release notes):

• Most trig code has been converted to Accelerate.framework
• HSV to RGB conversion is done manually (UIColor was too slow)
• Bitmaps are cached when generated
• Added -prepareForDiameter class method to preemptively create a cached bitmap (computed in background)
• Addressed bug that would inadvertently disable animations

Some possible issues:

• fixed Looks like I might be running into this http://stackoverflow.com/questions/10984732/why-cant-we-use-a-dispatch-sync-on-the-current-queue
• What happens if a color picker is created while -prepareForDiameter is calculating?
• Should bitmaps always cache by default?

Even more importantly, out of all of the changes made, which ones might not be great ideas? There are a lot of changes in that branch.

[RSully]

Regarding

What happens if a color picker is created while -prepareForDiameter is calculating?

I have changed the implementation to use NSCache (thread-safe) and NSOperations. It should be handled correctly now.

Should bitmaps always cache by default?

I'm still on the fence about this. I'm using NSCache now so even if they did cache by default it shouldn't be a huge burden. However, I have not been able to get it to evict an object (in the simulator) so I still want to do some more on-device testing.

[RSully]

I think it is safe to close this now. I just released v0.8.0 that includes many performance updates. If anyone has any issues please feel free to create a new issue and we can continue this discussion.