Based on your thought about setFrame: called multiple times, I do have some
interesting news, though not a full resolution: setFrameSize was getting
called repeatedly with the final size during the animation. I put logging
in setFrame{Size,Origin}: in the view whose constraints are altered. Here's
what it looks like during an expand:
2014-04-23 14:44:45.189 Pasteboard Inspector[1616:303] Setting frame
origin: {0, 91}
2014-04-23 14:44:45.190 Pasteboard Inspector[1616:303] Setting frame size:
{600, 352} XXX
2014-04-23 14:44:45.261 Pasteboard Inspector[1616:303] Setting frame size:
{600, 43}
2014-04-23 14:44:45.277 Pasteboard Inspector[1616:303] Setting frame size:
{600, 45}
..... cut to the middle...
2014-04-23 14:44:47.329 Pasteboard Inspector[1616:303] Setting frame size:
{600, 226}
2014-04-23 14:44:47.345 Pasteboard Inspector[1616:303] Setting frame size:
{600, 228}
2014-04-23 14:44:47.362 Pasteboard Inspector[1616:303] Setting frame size:
{600, 229}
..... cut to the end...
2014-04-23 14:44:50.179 Pasteboard Inspector[1616:303] Setting frame size:
{600, 352}
2014-04-23 14:44:50.229 Pasteboard Inspector[1616:303] Setting frame size:
{600, 352}
Okay, and here's what happens during collapse:
2014-04-23 14:45:23.047 Pasteboard Inspector[1616:303] Setting frame
origin: {0, 91}
2014-04-23 14:45:23.047 Pasteboard Inspector[1616:303] Setting frame size:
{600, 36}
2014-04-23 14:45:23.096 Pasteboard Inspector[1616:303] Setting frame
origin: {0, 91}
2014-04-23 14:45:23.096 Pasteboard Inspector[1616:303] Setting frame size:
{600, 36}
2014-04-23 14:45:23.097 Pasteboard Inspector[1616:303] Setting frame size:
{600, 347}
..... cut to the middle...
2014-04-23 14:45:25.554 Pasteboard Inspector[1616:303] Setting frame
origin: {0, 91}
2014-04-23 14:45:25.554 Pasteboard Inspector[1616:303] Setting frame size:
{600, 36}
2014-04-23 14:45:25.555 Pasteboard Inspector[1616:303] Setting frame size:
{600, 136}
2014-04-23 14:45:25.595 Pasteboard Inspector[1616:303] Setting frame
origin: {0, 91}
2014-04-23 14:45:25.596 Pasteboard Inspector[1616:303] Setting frame size:
{600, 36}
2014-04-23 14:45:25.597 Pasteboard Inspector[1616:303] Setting frame size:
{600, 133}
..... cut to the end...
2014-04-23 14:45:27.911 Pasteboard Inspector[1616:303] Setting frame
origin: {0, 91}
2014-04-23 14:45:27.911 Pasteboard Inspector[1616:303] Setting frame size:
{600, 36}
2014-04-23 14:45:27.912 Pasteboard Inspector[1616:303] Setting frame size:
{600, 36}
In other words, in the collapse, the view was getting the frame size set
twice on every animation update -- with the first size always being the
final goal size. I noticed that during the bogus frame set, the stack trace
is very similar but different in an important way - still triggered by
NSAnimationManager, but it's the superview frame change going through
resizeSubviewsWithOldSize: which triggers setFrameSize: on 'the' view. This
is indicative of the autoresize struts-springs model, yes?
The superview is a custom NSView only for the purpose of setting isFlipped;
it's the documentView of a scroll view's NSClipView. I noticed that, even
though this flip view had the Autoresize Subviews box OFF in IB, at runtime
after nib loading I found it was ON - perhaps some auto machinery by
scrollview? So I changed the code to force it NO after load. I was
extremely excited when I ran this change -- I found that it indeed did nuke
the unwanted frame change during the collapse, so that the log messages now
had a similar pattern during expand and collapse.
But did it solve my complaint? Well, it didn't look much better. I wonder
if possibly that setFrame: to the final destination frame at the very
beginning (see the XXX) is the problem? But if anything, would only cause a
blip not a long lasting jitter, right?
I suppose I could check the frame changes in FlipView to see if I need to
stop the same effect there. I wonder if possibly this is unavoidable when
inside NSScrollVIew.
Thanks for pointing me to something interesting!
On Wed, Apr 23, 2014 at 12:39 AM, Jakob Egger <ja...@eggerapps.at> wrote:
>
> > New questions:
> > 1. Is there any point in using addConstraint/removeConstraint in the
> NSAnimationContext grouping? Seems like it can go before beginGrouping.
>
> The important thing is that the frames are set inside the grouping.
> Updating constraints should not cause any frames to be set, only the
> layoutIfNeeded method should perform layout.
>
> > 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?
>
> Hm. NSLayoutConstraint conforms to NSAnimatablePropertyContainer, so you
> could perform an animation by animating the constant, eg.
> [[collapseConstraint animator] setConstant: 20]. However I don't know for
> sure if this works on 10.7, it doesn't say in the docs.
>
> > 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.
>
> I believe that the reason for the jitter is that frames are set multiple
> times, but I doubt there is anything you can do about it. You could set a
> breakpoint on setFrame: to try to debug, but I'm not sure that's worthwhile.
>
>
> A different way to approach your problem would be to use a (view-based)
> NSTableView or an NSOutlineView. Animations in table views are much easier
> to get right in my experience.
>
> Best wishes,
> Jakob
_______________________________________________
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
