Poor performance with shadows

[jdee]

Shadows can be expensive. This issue is a work in progress. There has been a bit of optimization by precomputing shadow paths when possible. The rotary dial mode is still problematic. This isn't recognizable from the demo on late-model hardware, but it's an issue.

[jdee]

With the addition of the shadow layer, all the demo views run well even on an old 2010 vintage iPod touch 4th gen. with iOS 6.1.6. Optimization is available for any situation, and shadow paths are automatically provided for all generated knobs.

The main remaining problem is that in order to optimize shadow generation with any custom image,
you have to provide a custom shadow path or at least specify the circularShadowPathRadius property, which can involve tedious measurement of an image. And providing a more complex path can be verbose and involved. It would be much nicer if a shadow path could be determined from the alpha
content of a UIImage and cached, rather than having the CALayer scan it frame by frame.

For now, the issue is largely addressed.

[jdee]

It turns out that the foreground layer also requires a shadow path in order to optimize performance. This now happens in the rotary dial and spin demos. See the tonearmShadowPath property in the spin view controller in each language, e.g.

This is a good workaround, but it's obviously tedious to supply this. The need for automation in this case is even greater now.