How difficult would it be to use core animation to make an NSView slide in an out of view like a sheet? Generally speaking, what would be involved in accomplishing this? I've been reading through the CA documentation, but it's been hard for me to pinpoint which parts are relevant to what I want to do since I have no experience with the framework.
Any tips at all would be much appreciated.
Thanks.
Since you're talking of a NSView, you're probably using Cocoa's animation support, not CA directly. In this case, you just need to set the view's frame through the view's animator object:
[theView setFrame:offscreenFrame];
[[theView animator] setFrame:finalFrame];
Unfortunately, Cocoa view animation interacts badly with the more advanced features of CA, like setting an easing. You might have more luck using NSViewAnimation instead, which is not Core Animation-backed and allows for a little more flexibility.
Related
I'm looking for a way to do frame-by-frame programmatically drawn animations in a MacOs application (not keyframe property animation). I have tried drawing to CALayers using the drawLayer:inContext: delegate method, calling setNeedsDisplay to draw each frame, however I'm getting poor performance doing it this way. Is there a recommended way to do this type of animation in Cocoa?
A good way to do entirely custom animations is by using CADisplayLink (iOS) or CVDisplayLink (macOS). CVDisplayLink is basically a timer that fires as often as the display refreshes.
You can then calculate your own timing functions based on the values you get off CVDisplayLink. The API is still C so it is a bit cumbersome to use, especially in Swift, but once you get how it functions it works like a charm.
I have only had good experiences with CVDisplayLink, especially with layers. They are really performant. I was able to animate 1000+ layers CVDisplayLink driven at 60fps without any problems.
If you need any help in using the API, feel free to ask!
Alternative:
If you want to use a more modern API, I can recommend SpriteKit. There are some nice animation APIs as well. And they perform really good. Apple uses it itself to draw more complex views (like the Memory Debugger in Xcode).
This is my first post here - but I've been a reader for a long time. Thank you so much for this site! :-)
I am currently working on a port of my XNA-based 2D engine from WP7 to iOS (5). I would prefer not to use OpenGL directly, because I prefer to invest my time more in gameplay than in technique. So I would be very happy to get an answer not involving OpenGL (directly).
The problem:
When I add an UIImageView to another UIView, there is a short delay before the UIImageView gets drawn. I assume, this is due to the caching the UIView-class performs before converting everything internally to OpenGL then drawing.
What I want:
Tell the UIView (superview) to perform all neccessary calculations for all subviews and then draw them all at once.
Currently the behaviour I observe ist: Calculate uiimageview_1, draw uiimageview_1, calculate uiimageview_n, draw uiimageview_n, ...
Dummycode of what I want:
// put code here to tell superview to pause drawing
for (int i = 0; i < 400; i ++)
{
add UIImageView[i] to superview;
}
// put code here to tell superview to draw now
Possible workaround (but coming from C# & Windows, I have no idea how to implement it efficiently in Objective-C on iOS) - I am afraid that this code is inefficient because large blocks of RAM had to be transferred (per frame!) on retina displays at native resolution:
for (int i = 0; i < 400; i ++)
{
add UIImageView[i] to superview;
}
// put code here to get a bitmap in ram from superview
// return bitmap and draw it in a view for the scenery/canvas
Any help on how to approach this "popping"-problem would be highly appreciated.
Thanks
Answering this will be a bit tricky. The exact behavior of Cocoa Touch is undocumented (an 'implementation detail' says Apple), so recommendations can only be given based on guessing and experience.
Instead of working with UIViews, you might want to try CoreAnimation. It abstracts 2D drawing and compositing operations without the overhead of a UI framework such as UIKit. It also much easier to use than programming OpenGL directly. UIKit uses CoreAnimation to do it's drawing, but augments it in many ways. This 'augmentation' might be exactly the reason why you're hitting performance problems.
Have a look at the tutorial and judge for yourself.
First of all - forget about UIKit's views. If you trying to port XNA game to iOS, I'd recommend to familiarize yourself with Cocos2D. It's more convenient than core OpenGL, and it'll give you performance you need.
How does the layout support of Cappuccino work? For example the centering and the automatik resizing.
The autoresizing masks are more or less implemented in this method:
http://github.com/280north/cappuccino/blob/master/AppKit/CPView.j#L987
On a more conceptual level, all views in Cappuccino are absolutely positioned. By not relying on the browser to lay things out, we always know exactly where everything is, and can make decisions accordingly.
Are you asking for an explanation on how to use the feature (one good place is this tutorial: http://cappuccino.org/learn/tutorials/automatic-layout/ ), or are you asking how it is implemented?
I'm working on a Snow Leopard app and I'm doing some view animations (swapping them) and I've seen some older examples using NSViewAnimation. I'm wondering if these are completely obsoleted by Core Animation?
It seems fairly simple for me to use
[[myView animator] setFrame:newSwapFrame];
But I'm just wondering if I'm missing something, or if NSViewAnimation is still relevant (other than for backwards compatibility).
Generally you should move to Core Animation for 10.5+ code. NSViewAnimation is fairly primitive and doesn't make as efficient use of the hardware. I can't think of any advantages of staying with NSViewAnimation other than 10.4 compatibility.
There are some cases where Core Animation is not suitable. For example, you can't put a WebView in a layer-backed view without funky things happening.
Also, text fields in layer-backed views don't use subpixel anti-aliasing, which can be a deal breaker.
If you're not using layer-backed views then your example of just using the animatable property support is definitely easier than using NSAnimation.
If you need to get window screenshot later (as example, to make transition animation between two window states), the Core Animated views (view with CAAnimation) may not been grabbed.
But CAAnimation is always working fast, and NSAnimation may slowing if CPU is too busy.
I know that keyframed transitions are possible in Core Animation via setting the path property on the CAAnimation instance. However, CATransition does not seem to have this functionality. Does anyone know any other ways to control the transition apart from setting the timing function?
The answer seems to be no. If you want to do this sort of thing, you have to add the CAAnimation yourself rather than depending on transitions. The transitions probably depend on some deep workings of CoreAnimation, because they don't work the same way normal animations do (they don't move the object in question, they control how the new content of the object replaces the old).