Tim Camber Tim Camber - 2 years ago 343
iOS Question

drawViewHierarchyInRect:afterScreenUpdates: delays other animations

In my app, I use

drawViewHierarchyInRect:afterScreenUpdates:
in order to obtain a blurred image of my view (using Apple’s
UIImage
category UIImageEffects).

My code looks like this:

UIGraphicsBeginImageContextWithOptions(self.view.bounds.size, NO, 0);
[self.view drawViewHierarchyInRect:self.view.bounds afterScreenUpdates:YES];
UIImage *im = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
/* Use im */


I noticed during development that many of my animations were delayed after using my app for a bit, i.e., my views were beginning their animations after a noticeable (but less than about a second) pause compared to a fresh launch of the app.

After some debugging, I noticed that the mere act of using
drawViewHierarchyInRect:afterScreenUpdates:
with screen updates set to
YES
caused this delay. If this message was never sent during a session of usage, the delay never appeared. Using
NO
for the screen updates parameter also made the delay disappear.

The strange thing is that this blurring code is completely unrelated (as far as I can tell) to the delayed animations. The animations in question do not use
drawViewHierarchyInRect:afterScreenUpdates:
, they are
CAKeyframeAnimation
animations. The mere act of sending this message (with screen updates set to
YES
) seems to have globally affected animations in my app.

What’s going on?

(I have created videos illustrating the effect: with and without an animation delay. Note the delay in the appearance of the "Check!" speech bubble in the navigation bar.)

UPDATE



I have created an example project to illustrate this potential bug. https://github.com/timarnold/AnimationBugExample

UPDATE No. 2



I received a response from Apple verifying that this is a bug. See answer below.

Answer Source

I used one of my Apple developer support tickets to ask Apple about my issue.

It turns out it is a confirmed bug (radar number 17851775). Their hypothesis for what is happening is below:

The method drawViewHierarchyInRect:afterScreenUpdates: performs its operations on the GPU as much as possible, and much of this work will probably happen outside of your app’s address space in another process. Passing YES as the afterScreenUpdates: parameter to drawViewHierarchyInRect:afterScreenUpdates: will cause a Core Animation to flush all of its buffers in your task and in the rendering task. As you may imagine, there’s a lot of other internal stuff that goes on in these cases too. Engineering theorizes that it may very well be a bug in this machinery related to the effect you are seeing.

In comparison, the method renderInContext: performs its operations inside of your app’s address space and does not use the GPU based process for performing the work. For the most part, this is a different code path and if it is working for you, then that is a suitable workaround. This route is not as efficient as it does not use the GPU based task. Also, it is not as accurate for screen captures as it may exclude blurs and other Core Animation features that are managed by the GPU task.

And they also provided a workaround. They suggested that instead of:

UIGraphicsBeginImageContextWithOptions(self.view.bounds.size, NO, 0);
[self.view drawViewHierarchyInRect:self.view.bounds afterScreenUpdates:YES];
UIImage *im = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
/* Use im */

I should do this

UIGraphicsBeginImageContextWithOptions(self.view.bounds.size, NO, 0);
[self.view.layer renderInContext:UIGraphicsGetCurrentContext()];
UIImage *im = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
/* Use im */

Hopefully this is helpful for someone!

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download