Ugh, forget the youtube video, it gets too resampled. Just download the file and watch it if yyou want.
https://dl.dropboxusercontent.com/u/16749188/Animation%20jitter.mov On Mon, Apr 21, 2014 at 6:15 PM, Julian <jpell...@gmail.com> wrote: > Hi Jakob, thanks for the reply. I stopped checking the list every day. > Going backwards: > > It may be an expensive operation to remove, but these macs seem to be able > to handle it. I'm not noticing any problem on my 2.4 ghz Core 2. > > > > See also the section "Animating Changes Made by Auto Layout" on the > following page, which has a better example: > Thanks for directing me to the correct usage! I added this however, no > change, I think that the layout is already current. > > I managed to get the expand method animating rather smoothly. However, I > have a problem with the collapse. I determined that I have additional frame > changes beyond the immediate superview. On the collapse I am performing > layout on two views up. > > -(void) collapse { > [self.superview.superview layoutSubtreeIfNeeded]; > [self addConstraint:collapseConstraint]; > > if ([NSAnimationContext > instancesRespondToSelector:@selector(setAllowsImplicitAnimation:)]) > { > > [NSAnimationContext beginGrouping]; > [[NSAnimationContext currentContext] setAllowsImplicitAnimation: > YES]; > > // animation options... > > [self.superview.superview layoutSubtreeIfNeeded]; > [NSAnimationContext endGrouping]; > } > [self disableControls]; // can be commented out no change to jitter > } > > New questions: > 1. Is there any point in using addConstraint/removeConstraint in the > NSAnimationContext grouping? Seems like it can go before beginGrouping. > 2. As you can see in the code, I check to see if the implicit animation > setting is there at runtime (added in 10.8). AFAICT there is no simple way > to do the animation in 10.7 when the autolayout was added. Apple had an > oversight in 10.7 and fixed it in 10.8? > 3. The jitter problem. It's even more severe when the animation duration > is shorter. I'm using 0.6 as the production duration. > 4. (for good measure) Also, watch the focus ring while these animations > are happening. I don't know if this is a Cocoa issue, or another symptom of > my problematic code. The NSButton has the focus, but that view's frame is > definitely not changing as a result of layout, as you can see. > > https://www.youtube.com/watch?v=Vi5tEMiMQZ0&feature=youtu.be > > I don't know why in the new recording, the jitter looks as bad on the > expand as it does on the collapse - on my computer, the collapse is much > worse. Some artifact of the quicktime capture? > > Thanks, > Julian > > > On Fri, Apr 18, 2014 at 4:25 AM, Jakob Egger <ja...@eggerapps.at> wrote: > >> Hi Julian, >> >> The jittering is probably a result of misusing the animator proxy! The >> animator proxy is used when you want to directly change properties, for >> example the frame of a view, or the alpha value. When you use autolayout, >> the frame will be set by the view's layout method, which does not use the >> animator. Therefore you must capture the change using >> setAllowsImplicitAnimation. >> >> When you perform an animation in autolayout, make sure that the views are >> layed out before the animation starts. You must call -layoutSubtreeIfNeeded >> twice. >> >> Try the following: >> >> -(void) expand { >> [view.superview layoutSubtreeIfNeeded]; >> [NSAnimationContext beginGrouping]; >> [[NSAnimationContext currentContext] setAllowsImplicitAnimation: YES]; >> [[NSAnimationContext currentContext] setDuration:2]; >> [NSAnimationContext currentContext].timingFunction = >> [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionLinear]; >> [view removeConstraint:collapseConstraint]; >> [view.superview layoutSubtreeIfNeeded]; >> [NSAnimationContext endGrouping]; >> } >> >> See also the section "Animating Changes Made by Auto Layout" on the >> following page, which has a better example: >> >> https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/AutoLayoutbyExample/AutoLayoutbyExample.html >> >> Furthermore, adding/removing constraints in autolayout is an expensive >> operation. The only cheap operation is to change the constant of a >> constraint. Maybe it would be possible to do this in your case? Since the >> constraint you are removing limits the height, maybe just setting the >> constraint's constant to a high value would be faster? >> >> Best wishes, >> Jakob >> >> >> Am 14.04.2014 um 23:42 schrieb Julian <jpell...@gmail.com>: >> >> > I'm animating frame changes from autolayout. Code to trigger the expand >> is >> > shown here. I added QuartzCore.framework to my link libraries, and >> checked >> > layer backing for the window's view. >> > >> > -(void) expand { >> > [NSAnimationContext beginGrouping]; >> > [[NSAnimationContext currentContext] setAllowsImplicitAnimation: >> YES]; >> > [[NSAnimationContext currentContext] setDuration:2]; >> > [NSAnimationContext currentContext].timingFunction = >> > [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionLinear]; >> > >> > [[view animator] removeConstraint:collapseConstraint]; >> > >> > [[view animator].superview layoutSubtreeIfNeeded]; >> > [NSAnimationContext endGrouping]; >> > } >> > >> > The collapseConstraint is a constraint that limits the view to a short >> > height, however there is another constraint that establishes the height >> at >> > its natural height, with a lower priority. collapseConstraint trumps it, >> > until it's removed, then boom! layout expands it and moves down the >> views >> > below. >> > >> > 2 questions: >> > >> > 1. How do I avoid using -setAllowsImplicitAnimation:? From the >> > documentation, it sounded like using the animator proxy automatically >> > handled implicit animations, yet if I remove that line, there are no >> > animations. >> > >> > 2. I added a recording of this expand animation, and the collapse >> > animation, on youtube here. http://youtu.be/fSu0EqE9mnM >> > >> > There is significant vertical jitter in the animation of the expanding >> > view. For example, the horizontal line, which is an NSBox subview at the >> > top edge of the expanding view, flickers in/out of visibility. The other >> > lines inside the views that are getting shifted down don't have this >> > problem. What might cause this? Perhaps some views inside are changing >> > height as the frame changes? >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> 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: >> https://lists.apple.com/mailman/options/cocoa-dev/jpellico%40gmail.com >> >> This email sent to jpell...@gmail.com > > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
