Load performance pains about rscolorpicker HOT 5 CLOSED

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: 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":

from rscolorpicker.

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.

from rscolorpicker.

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.

from rscolorpicker.

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.

from rscolorpicker.

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.

from rscolorpicker.