replacing NSViewAnimation with CoreAnimation

  • Hi,

    I just wonder did Apple replace NSViewAnimation internaly with
    CoreAnimation or
    should I detect Leopard and use CoreAnimation instead of
    NSViewAnimation under Leopard?

    All the best
        Christoph
  • On Nov 21, 2007, at 6:25 AM, Christoph Vogelbusch wrote:

    > I just wonder did Apple replace NSViewAnimation internaly with
    > CoreAnimation or
    > should I detect Leopard and use CoreAnimation instead of
    > NSViewAnimation under Leopard?

    As I found out a while ago, NS*Animation and CoreAnimation are two
    completely different things. CoreAnimation does not and probably will
    not replace NSViewAnimation.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • On Nov 21, 2007, at 8:25 AM, Christoph Vogelbusch wrote:

    > Hi,
    >
    > I just wonder did Apple replace NSViewAnimation internaly with
    > CoreAnimation or
    > should I detect Leopard and use CoreAnimation instead of
    > NSViewAnimation under Leopard?
    >

    If you're NSViewAnimation works, and you want to continue to target
    Tiger as well as Leopard, I don't see why you'd want to change to the
    new Animation Proxy api. It's just going to add to your code support.

    Mind you, if you're writing something new and only targeting Leopard
    you can't beat just doing

    [[myView animator] setFrame:newRect];
  • Well the problem/question is:
    Is NSViewAnimation SLOWER then CoreAnimation (because it uses no
    layers).
    If so I would use NSViewAnimation for Tiger and CoreAnimation for
    Leopard.
    But there is no reason why Apple didn't rewrite some of the
    NSViewAnimation code for Leopard. I'm technically it's teh same thing
    I'm doing here. Intercepting ViewAnimations put them in a animation
    context and fire them together.

    SO the Question is: Is NSViewAnimation under Leopard as fast as
    CoreAnimation (and uses layers) or not?

    All the best
        Christoph

    Am 21.11.2007 um 21:10 schrieb Scott Anguish:

    >
    > On Nov 21, 2007, at 8:25 AM, Christoph Vogelbusch wrote:
    >
    >> Hi,
    >>
    >> I just wonder did Apple replace NSViewAnimation internaly with
    >> CoreAnimation or
    >> should I detect Leopard and use CoreAnimation instead of
    >> NSViewAnimation under Leopard?
    >>
    >
    > If you're NSViewAnimation works, and you want to continue to target
    > Tiger as well as Leopard, I don't see why you'd want to change to
    > the new Animation Proxy api. It's just going to add to your code
    > support.
    >
    > Mind you, if you're writing something new and only targeting Leopard
    > you can't beat just doing
    >
    > [[myView animator] setFrame:newRect];
    >
    >
  • On Nov 21, 2007, at 4:05 PM, Christoph Vogelbusch wrote:

    > Well the problem/question is:
    > Is NSViewAnimation SLOWER then CoreAnimation (because it uses no
    > layers).
    > If so I would use NSViewAnimation for Tiger and CoreAnimation for
    > Leopard.
    > But there is no reason why Apple didn't rewrite some of the
    > NSViewAnimation code for Leopard. I'm technically it's teh same
    > thing I'm doing here. Intercepting ViewAnimations put them in a
    > animation context and fire them together.
    >
    > SO the Question is: Is NSViewAnimation under Leopard as fast as
    > CoreAnimation (and uses layers) or not?

    As Nick said  NS*Animation isn't related to Core Animation.

    View animation has never had a goal of running at a specified number
    of frames per second as far as I know. Core Animation on the other
    hand...

    View animation is intended for resizing or moving views around in a
    UI, not animating all sorts of bits.

    That said, no I don't believe it has been rewritten to use Core
    Animation. I doubt that NSViewAnimation changed at all to use the
    animatable properties support (which is where this would have migrated
    to, had it migrated.. not to Core Animation).

    But the person who could definitively say isn't likely to read this
    message this week what with Thanksgiving and all (or perhaps ever,
    since there is no guarantee that anyone at Apple will read anything on
    the list)

    Of course if you really want to know if it uses it you could always
    use the debugging tools.
  • Scott Anguish <scott...> wrote:

    > [[myView animator] setFrame:newRect];

    May I use this opportunity to ask a related question: how do I animate
    scrolling in an NSScrollView?

    It seems that NSClipView's scrollToPoint: only calls
    translateOriginToPoint:, which I'm not sure how to animate.  I tried
    scrolling manually by doing

      [[[myScrollView contentView] animator] setBoundsOrigin:newOrigin];

    but this throws an exception

      [<NSClipView 0x1620e730> valueForUndefinedKey:]: this class is not key
      value coding-compliant for the key boundsOrigin.

    Any ideas?

    --
    Stefan Haller
    Ableton
    http://www.ableton.com/
  • On Nov 22, 2007, at 6:11 AM, Stefan Haller wrote:

    > Scott Anguish <scott...> wrote:
    >
    >> [[myView animator] setFrame:newRect];
    >
    > May I use this opportunity to ask a related question: how do I animate
    > scrolling in an NSScrollView?

    Sure.

    You'd have to use something other than an animatable proxy.  Only
    selected properties are already animatable in NSView and NSWindow.
    NSAnimation is probably your best bet.

    I thought the list of animator proxy animatable properties was in the
    release notes.. but I can't seem to find them at the moment.

    In the meantime, I'd suggest filing an enhancement request for
    NSScrollView to support animatable property container animation for
    scrolling. (and please send me the id off list if you do)
  • Scott Anguish <scott...> wrote:

    > I thought the list of animator proxy animatable properties was in the
    > release notes.. but I can't seem to find them at the moment.

    It's in <http://developer.apple.com/releasenotes/Cocoa/AppKit.html>:

    : Basic default animation parameters are provided for the following
    : NSView and NSWindow properties, such that they will animate
    : automatically when assigned a new target value via the view or
    : window's animator:
    :
    : for NSView: alphaValue, frame, frameOrigin, frameSize, frameRotation,
    : frameCenterRotation, bounds, boundsOrigin, boundsSize,
    : backgroundFilters, contentFilters, compositingFilter, shadow

    This sounds to me as if it should be possible to animate the
    boundsOrigin of an NSClipView.  However, it says this under the heading
    "Using Layer-Backed Views"; does that mean that I have to make the
    NSClipView layer-backed for this to work?  Do I want to?  I certainly
    don't want to make the scroll view's document view layer-backed, as it
    can become pretty large.

    --
    Stefan Haller
    Ableton
    http://www.ableton.com/
  • On Nov 23, 2007, at 3:27 AM, Stefan Haller wrote:

    > Scott Anguish <scott...> wrote:
    >
    >> I thought the list of animator proxy animatable properties was in the
    >> release notes.. but I can't seem to find them at the moment.
    >
    > It's in <http://developer.apple.com/releasenotes/Cocoa/AppKit.html>:

    I thought I had seen it there. but I couldn't find it earlier.
    Thanks!  This will be in the NSView and NSWindow reference
    documentation for the next release. And the animation book shortly
    afterwards
  • Stefan Haller <haller...> wrote:

    > It's in <http://developer.apple.com/releasenotes/Cocoa/AppKit.html>:
    >
    > : Basic default animation parameters are provided for the following
    > : NSView and NSWindow properties, such that they will animate
    > : automatically when assigned a new target value via the view or
    > : window's animator:
    > :
    > : for NSView: alphaValue, frame, frameOrigin, frameSize, frameRotation,
    > : frameCenterRotation, bounds, boundsOrigin, boundsSize,
    > : backgroundFilters, contentFilters, compositingFilter, shadow
    >
    > This sounds to me as if it should be possible to animate the
    > boundsOrigin of an NSClipView.  However, it says this under the heading
    > "Using Layer-Backed Views"; does that mean that I have to make the
    > NSClipView layer-backed for this to work?  Do I want to?  I certainly
    > don't want to make the scroll view's document view layer-backed, as it
    > can become pretty large.

    I tried it, and yes, setWantsLayer:YES on the scroll view makes it work.
    However, it only works for reasonably small document views; for larger
    views, I get either

      -[_NSViewBackingLayer(0x172c0cf0) p={0, 0} b=(0,0,817,1.00355e+06)
      superlayer=0x15f9b400 display]: Ignoring bogus layer size
      (817.000000, 1003552.000000)

    or

      CoreAnimation: 817 by 6848 image is too large for GPU, ignoring
      CoreAnimation: rendering error 500

    So it seems that the CATiledLayers feature which the release notes talk
    about doesn't seem to work.  Or is there something I have to do to
    enable it?

    For now I'm back to animating it manually using NSAnimation, which works
    just fine; although it does look a little less smooth (and results in a
    lot more CPU load, of course).

    --
    Stefan Haller
    Ableton
    http://www.ableton.com/
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today