I would like to have a UIView
subclass that implements a method similar to setNeedsDisplay
, except that redrawing (i.e., that would usually be called via drawRect:
) will occur in a background thread sometime soonish, rather than at the end of the current update cycle.
It might be called setNeedsAsynchronousDisplay
. Or the existing setNeedsDisplay
could get hijacked and not cause redraw at the end of the cycle, or whatever, as long as it lets the redraw not happen on the main thread blocking screen updating an interaction until its completed.
Until the redraw occurs, the view can continue to use its current drawn representation.
Is something along these lines reasonably doable?
Thanks!
Yes it is possible. You will probably need to generate the content view as an image in the background and push the images into a nsdictionary or array.
So while your background is generating the images you can just show the image in drawrect function by rendering the image, providing the image has been generated.
A WWDC video that shows how to do it: WWDC 2012 session 211 - Building Concurrent User Interfaces on IOS. Here is the video description:
For a great user experience, it's essential to keep your application responsive while it renders complex UI elements and processes data. Learn how to use concurrency at the UIKit layer to perform drawing and other common operations without blocking user interaction.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With