In fact I’m pretty sure this behaviour dates back to NSOpenGLView and possibly others. I suppose technically this has always been the case; that overlapping views weren’t supported at all before layer-backing. But I had forgotten, so it took a little bit of experimenting to jog my memory. It’s interesting that when not layer-backed, all… Read more
It’s supposed to invoke your block when all the animations in the current transaction have completed. It doesn’t; it runs it as soon as the transaction is committed. Le sigh. It does appear to do it from the main runloop at least, as documented. So there is technically a delay, as a consequence of that… Read more
Obnoxious undocumented behaviour #bajillion: you can’t disable implicit animation with setDisableActions: inbetween begin & commit on the same SCNTransaction. It just doesn’t work. Update: rdar://problem/12758940
There’s no API to get any kind of performance information from an SCNView, even as basic as a rolling frame rate. But it’s not hard to add – you can be notified when each frame is drawn by overriding the -draw method. For example: Update:However, if you’re layer-backed the “draw” method isn’t used. Instead you… Read more
It’s not explicitly documented either way, but it is perfectly valid, evidently, to attach the same SCNGeometry to multiple SCNNodes. Works as you’d expect – changes to the geometry are reflected across all the nodes identically. It doesn’t appear to have any performance impact though, oddly. At least not in fairly trivial scenes. It might… Read more
You can create a CAAnimation and hand it to -[SCNNode addAnimation:forKey:] on as many nodes as you want. No apparent side-effects. I just couldn’t find this documented anywhere.
If you try to add an animation to an SCNNode that’s not yet part of a scene graph, nothing will happen. It won’t give any indication of failing, and the performance of rendering implies it’s still running them, but there will be no visible effect. So, addChildNode: and then addAnimation:forKey:.