I would like to implement a new CATransition.
For example, let's say I would like to do this effect: a n by m array of two sided layers that have a portion of the source image on one side, and the a portion of the destination image on the other side. Each layer would rotate around its x axis by 180 degrees to reveal the other side. Can such a logic (animated CALayers) be used for a CATransition ?
I don't think you can do this. The only way to customize CATransition beyond the built-in types and subtypes, is by using a CIFilter(from iOS 5.0 or OSX 10.5). And the only way to create a custom CIFilter beyond chaining and configuring built-in filters is, according to the doc :
You can subclass CIFilter in order to create:
A filter by chaining together two or more built-in Core Image filters (iOS and OS X)
A custom filter that uses an image processing kernel that you write (OS X only)
So doing this based on CALayer animations is not possible.
On OSX this should be managable with some math work, but not directly using CALayers animations. In iOS this is simply not possible.
Instead of doing a CATransition you could achieve the same effect by using layers directly, but obviously it would not integrate as easily in your UI code.
I have written a transition effect like you describe, but it was not a CATransition. Instead, I created my own method to handle view transitions, and invoke that.
My transition cut the two views into vertical slices, and then did an animation where I start rotating the slices around their Y axes, starting with the left-most slice and working to the right, which creates a cool-looking cascade effect. It took quite a bit of work with CAAnimationGroup obbjects, plus using beginTime for each strip's animation to stagger it's beginning. That one transition animation took about 5 pages of code.
Related
I am currently attempting to create an interactive, informative poster, with regards to Anti-Aliasing techniques and effects. The application is written in Obj-C within Xcode, and makes use of OpenGL and Cocoa functionalities.
I am attempting to create a small animation to display the difficulties of drawing a diagonal line on a pixel grid, however am having real trouble getting my head around the animation aspect.
I am aiming for something with a similar look and feel to this:
I have currently drawn a grid using OpenGL primitives:
,
and would like the effect above to be replicated within my grid, however without the shading yet (that is the next part), so just plain black pixels coloured step by step along the line.
I am new to both OpenGL and Obj-C, so am unsure whether best to implement the animation within OpenGL, or using OSx Core Animation - neither of which I have used before.
The OpenGL drawing takes place within my MyOpenGLView class, with the drawing done in a drawAnObject method, which is then called within the drawRect method.
Any help would be much appreciated, thanks in advance!
I've created many types of interfaces using the Cocoa API — some of them using documented basic animation techniques and others simply by experimenting (such as placing an animated .gif inside an NSImage class) — which had somewhat catastrophic consequences. The question I have is what is the correct or the most effective way to create an animated and dynamic GUI so that it runs optimally and properly?
The closest example I can think of that would use a similar type of animation would be something one might see done in flash on any number of interactive websites or interfaces. I'm sure flash can be used in a Cocoa app, although if there is a way to achieve a similar result without re-inventing the wheel, or having to use 3rd party SDKs, I would love to get some input. Keep in mind I'm not just thinking of animation for games, iOS, etc. — I'm most interested in an animated GUI for Mac OS X, and making it 'flow' as one might interact in it.
If u wish to add many graphics animations, then go for OpenGLES based xcode project for iOS. That helps u to reduce performance problem. You can render each of the frames in gif as 2D texture.
I would recommend that you take a look at Core Animation. It is Apples framework for hardware accelerated animations for both OS X and iOS. It's built for making animated GUIs.
You can animate the property changes for things like position, opacity, color, transforms etc and also animate gradients with CAGradientLayer and animate non-rectagunal shapes using CAShapeLayer and a lot of other things.
A good resource to get you started is the Core Animation Programming Guide.
I am trying to implement a Fan view like the ones in the Mac OS X dock, such as the Downloads and Documents folders, using Cocoa.
I am currently adding a button on a transparent window's content view and animating the button's frame using NSViewAnimation (group animation). But the animation is not as smooth as expected.
Is there any other optimized way for implementing this?
You should be using Core Animation for this. You should create a transparent view/window that's large enough to contain your whole animation. You should then use CALayer objects to perform the actual animation.
Core Animation layers are essentially high-level lightweight wrappers around OpenGL surfaces and the rendering of the layers is done by the GPU, giving much better performance than CPU-managed animation such as NSViewAnimation.
Bear in mind that because Core Animation layers are lightweight, they don't have any event-handling built into them, so you'll need to do all the mouse tracking in your view/view controller.
Your other option is using layer-backed views (which have their own CALayer) and animating the buttons' positions using the animator proxy. This may be enough to achieve what you want, and because the buttons are still full NSButton objects they still have all the NSView event handling.
You should probably read the Animation Overview to give you a better idea of how all these technologies work.
I've been trying to figure this out for a while but I can't seem to get it. How would I swap two NSViews using a push transition (like what UINavigationController does on iOS)? What I've tried so far:
Using an NSAnimation subclass <-- too slow
Using NSViewAnimation and MGViewAnimation <-- too slow
Using the NSView animator proxy <-- too slow
Using CATransition <-- I can't use this because CATransition requires the views to be layer backed, and layer backing views causes text rendering glitches as well as various other graphical artifacts
The first 3 options are probably too slow because you're trying to use them without layer-backing your views. To do animation in AppKit, you're going to need to have your views backed by layers.
It seems that the animation is slow because I'm animating a pretty large view. I don't think there's any way around that other than the good old image swap trick (taking an image of the view and animating that instead of the view itself).
I would like to create a custom NSView that takes a layered approach to painting. I imagine the majority of the layers would be the same width and height as the backing view.
Is it appropriate to use the Core Animation classes like CALayer for this task, even though I don't expect to need much animation? Is there a more appropriate approach?
To clarify, the view is not meant to be like a canvas in a Photoshop-like application. It more of a data display that should allow for user interaction (selecting, moving, scrolling, etc.)
If it's display and layout you're after, I'd say that a CALayer-based architecture is a good choice. For the open source Core Plot framework, we construct all of our graphs and plot elements out of CALayers, and organize them in a regular hierarchy. CALayers are lightweight and use almost identical APIs between Mac and iPhone. They can even be made to respond to touch or mouse events.
For another example of a CALayer-based user interface, my iPhone application's entire equation entry interface is composed of CALayers, including the menu that slides up from below. Performance is slightly better than that of my previous UIView-based implementation, but the same code also works within my preliminary desktop version of the application.
For a drawing program, I would imagine it would be important to hold a buffer of the bitmap data. The only issue with using a CALayer is that the contents property is a CGImageRef. To turn that back into a graphics context for doing further drawing can be a bit of a pain. You'd have to initialize a new context, draw the bitmap data into it, then do whatever drawing operations you wanted to do, and finally turn that back into a CGImageRef. You probably wouldn't be able to avoid doing a number of pretty large memory allocations, which is virtually guaranteed to slow your program way down.
I would consider holding an off-screen buffer for each layer. Take a look at the Quartz CGLayerRef object. I think it probably does what you want to do: it's an off-screen buffer that holds things you might want to draw repeatedly. You can also quickly get a CGContextRef whenever you need it so you can do additional drawing. And you can always use that CGContextRef with NSGraphicsContext if you want to use Cocoa drawing methods.