Re: UIView animation (backgroundColor) + drawRect:
Re: UIView animation (backgroundColor) + drawRect:
- Subject: Re: UIView animation (backgroundColor) + drawRect:
- From: Roland King <email@hidden>
- Date: Thu, 03 Mar 2011 22:18:03 +0800
As ever, thanks very much David. I figured there was *something* going on when drawRect: was defined but I wouldn't have figured out what without this help.
In this case a crossfade in every case for that particular view works perfectly, I implemented what you suggested and it looks so much better, it's amazing the difference that even a .3-.5 second smooth transition can make, just takes the edge off something which was quite harsh before, looks much more professional.
Got the point (again) on using simple subviews when possible, a mistake I've made before. In this particular case I don't think that was going to work, but I'm very happy with what I have now.
Andreas, thanks for your reply too. You had pretty much exactly the same thoughts I did and we both tried the same ideas, with the same ..AllowAnimatedContent etc and got the same results; hope David's reply was useful to you too, it goes in my 'keepers' file.
On 03-Mar-2011, at 5:10 AM, David Duncan wrote:
> On Mar 2, 2011, at 5:12 AM, Roland King wrote:
>
>> I was trying to animate the backgroundColor of one of my UIView subclasses yesterday using
>>
>> [ UIView animateWithDuration:2.0 animations:^{ [ myView setBackgroundColor:someColor ]; } ];
>>
>> but no matter what the duration set, the background color was changing instantly. Whilst looking to see if there were two places I called setBackgroundColor: (there weren't) I realized that my UIView subclass has its own drawRect: method (this view is basically a piece of paper with some lines drawn on it, so it needs a custom drawRect: method). Commenting that out, the view background animated properly, but of course I had no content. Even just adding an empty drawRect: method was enough to defeat the animation.
>
>
> When you implement -drawRect:, the background color of your view is then drawn into the associated CALayer, rather than just being set on the CALayer as a style property. Now Core Animation can animate both transitions, but UIView disables the animation of a layer's contents, which thus prevents you from getting a contents crossfade (as in the vast majority of cases this wouldn't be what you want).
>
> The crossfade may be exactly what you want in this case. Likely the best way to defeat UIView's override in this case may be to create a subclass of CALayer that overrides -actionForKey:. In that override, you would check for the @"contents" key and return a CABasicAnimation ([CABasicAnimation animation] should do it) and in all other cases return what the default implementation does. This has the downside that you will *always* cross fade and you won't be able to integrate with UIKit's animation APIs (you just get animation for contents on all the time).
>
> Another solution would be to use a super view that contains just the background color and have your lines composited over it (assuming they are simple lines this could be done with simple subviews that are sized for each line). This would allow you to avoid -drawRect: entirely, which would allow you to animate the background color and may offer some memory usage benefits (if you can use subviews).
> --
> David Duncan
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden