Doing completely custom animations with Core Anima

Question

The article

https://www.objc.io/issues/12-animations/animating-custom-layer-properties/

has this to say about doing completely custom animations with Core Animation:

Suppose that instead of implementing our clock face using individual layers, we wanted to draw the clock using Core Graphics. (In general this will have inferior performance, but it’s possible to imagine that there are complex drawing operations that we might want to implement that would be hard to replicate using ordinary layer properties and transforms.) How would we do that?

In other words, we draw each frame of the CA manually using CG, because our animation is too complex to be done only with the built-in CALayer functionality.

The question is about the inferior performance.

1. Since CG runs on the CPU, doesn't this risk blocking the main thread?
2. Could this be a reason to use SpriteKit instead of CA (since SpriteKit runs on GPU and won't block the main thread)?

Answer 1

1. Yes. To your first question. Drawing with Core Graphics (Quartz or CG) is CPU bound and will drastically slow every aspect of your app.... If the preparation, drawing, compositing and presentation eat into frame time, your app will visibly stall and slow its frame rate to get the drawing done. Even if this is less than 1 frame per second.

You see this when outputting a big PDF. Core Graphics busily renders at the expense of all other activity, favouring quality of output over all other factors. Partially this is because its origins are PostScript, targeting printed output, where quality is the primary objective, but also because it’s remained a quality centric framework for the creation of imagery, not animations.

2. SpriteKit versus CA is a much more nuanced argument than SpriteKit/CA vs CG

Understanding the different priorities, capabilities and performance characteristics of these frameworks reveals how best to use them together, and when to choose them in exclusivity.

In the case of CA and CG, the naming conventions convey dependency and interoperability that’s not necessarily true, necessary, or there, but they can be combined effectively, and very well. It's just a bit of a balancing act because they do some things very differently.

CG = Core Graphics

CA = Core Animation

Core Animation is what it says on the tin: very good at animating things. But it’s also got prodigious creative content creation tools. Things that might surprise you because it's not a framework spoken of much. Many of its key abilities are obscured by the UIKit wrappers that use them.

The article you’ve linked to has completely avoided discussing Core Animation’s content creation tools, which aren’t half baked, and are quite good. Particularly for an animation framework. You could make all the components required, and the perfect clock animation, entirely in Core Animation, without using any of the slower Core Graphics drawing. I’m not sure why that article doesn’t illustrate these capabilities.

On Core Animation content creation layers, here's two of them:

CAShapeLayer can make and animate the drawing of any shape or combination of shapes. CATextLayer fully supports NSAttributedString, and all its properties, and animating them, too.

Think of Core Animation like a Flash and QuickTime inspired, closed source, platform specific API for highly performant animation and visual interactivity creation, from scratch.

• As a drawing and content creation framework, CALayers do not have all the capabilities of Core Graphics. But they're nowhere near limited in the ways SpriteKit is, either.

• As an animation and interactivity framework, Core Animation is a better and (in many ways) more performant graphics, animation and event based game engine than Sprite Kit, without some of the more specific add-ons included in SpriteKit.

CALayers are not just simple things. They're capable of drawing content, and masking it, too. And then being highly animated in all manner of wonderful ways, including a pseudo 3D rotational space, complete with perspective distortion.

Missing from Core Animation, but in SpriteKit are:

1. Sound: there’s two different ways to play sound in SK, none in CA without rolling own
2. Game loop: whilst SK optimises for events, it’s also got a game loop it’s built around
3. Physics: You’ll need to use UIKit Dynamics with Core Animation Layers to get physics
4. Image Packing: Need to make your own file handling for textures, and their unpacking
5. Visual Scene Editor: Arguably not much of a loss. Said from a designer’s perspective
6. Visual Particle Editor: this is more of a loss. Harder to make good effects without one
7. SKActions: But CA has both implicit/explicit animation and/or CAKeyFrameAnimation

Outright negatives of using SpriteKit:

1. Doesn’t play well with UIKit and its wonderful layout abilities when you want them
2. Peculiar bugs because it’s given minimal (seemingly) resources and bug testing
3. Very small community of users providing a small pool of mostly trivial Q&A support
4. Almost no support to mention from Apple, their forums are a wasteland of sorrow
5. The documentation is abysmal, mostly out of date and/or meaningless
6. None of the myriad of examples and demonstrations common to game engines
7. Understanding the workflow, paradigms and processes is learnt through osmosis
8. The Scene Editor is slow, poorly designed, malnourished and fits poorly in Xcode
9. No NSAttributedString support for labels and other textual presentation needs

---

Some historical guff I'll delete once adding answer to part two:

Quick recap of Core Graphics History, with a pertinent twist…

PostScript on the Mac is largely responsible for Desktop Publishing being a thing, and Mac success in the new and burgeoning niches of design and creativity computing markets it assisted in creating. These markets kept Apple alive whilst IBM/Intel/Microsoft attacked the cost and compatibility conscious ‘productivity’ and enterprise markets. Digital creatives are now frustrated and furious with Tim Cook’s Apple for milking the iPhone cash cow whilst failing to acknowledge, honour, care for or even keep pace with the capacity of modern desktop creativity.*

Some other dribble to consider when choosing a framework:

With the biggest cash reserve in consumer and creative computing history, they’re also failing to innovate in creation of tools for creativity. This feels (and looks) much like a betrayal of both Apple core values/traditions and the energies and enthusiasm of those that have committed to learning and using Apple centric creative tools over the lean decades. It’s inarguable that the creativity “cool” helped Apple be “cool”, providing the expectation and adoption of the iPod that lead to the iPhone and iPad.

Some of lustre of the brand is definitely falling off due to the tactless and graceless cash-grab focus on the iPhone. This is worrying for one simple reason that factors into these types of decisions: the uptake of SpriteKit has been minimal. Apple could decide to cost cut on its already lean development team to make bigger profits, as it seems profits are trumping all other motives in the new Apple. There's nowhere near a proportionate spend on innovation in frameworks and software development resources compared to those profit increases from the iPhone.

Apple shows no signs of understanding the need, nor desiring to actively and passionately invest in making new frameworks as good as they could be, or stable. Validating, and therefore attracting developers to new frameworks requires a transparent effort Apple seems unwilling to make. Apple seems dismissive and contemptuous of the time and effort expected and required to learn, adopt and use new frameworks. And utterly presumptive in their expectation developers will take the risk of adopting Apple only technologies that could be shuttered on a profit seeking whim.

Sprite Kit and Scene Kit are suffering a ridiculously long gestation period, and several showstopper bugs in prior releases. In conjunction with with terribly poor developer communication and a complete lack of apparent care for growth in coder confidence and adoption, this has lead to truly anaemic adoption rates.

Without strong adoption, Apple could decide to drop SpriteKit, rather than let it limp along as it has been.

It's fair to say that the continued success of cocos2D-X is a direct result of Apple's failure to make SpriteKit all it could and should be. A complete failure to support, communicate, manage and update its problems, in both a timely and considerate manner, has created a strong desire to avoid using SpriteKit, and much developer uncertainty and trepidation in those that do.

With their near limitless budget for development talent, this sort of thing should be a source of embarrassment and criticism of Apple, and spur intense scrutiny of their other "initiatives" and dabbles with "innovation". For reasons I don't understand, it's not the done thing to critically think about what Apple does and doesn't do, and the influences and impacts those choices have.

I think it’s fair to say their hiring of in-house software developers and quality of software output is nowhere near matching the growth of the iOS platform in terms of hardware sales, app store revenue, reach and their market influence. This will soon have consequences more apparent than the skinny user base of Sprite Kit and near non-existent use of SceneKit.