Create prerendered animations using a sequence of static images. Store canned animations in your Watch app bundle so that they can be presented quickly to the user. Canned animations also let you deliver high frame rates and smoother animations. Creating animations dynamically from your WatchKit extension and transferring them to Apple Watch adds a delay before playback can begin.
This is not a good sign as to the power of the watch, unless I'm drastically misinterpreting things.
This is referring to the delay in the transmission between your phone and the watch. By storing the static, pre rendered animations on the watch itself, they're ready to play immediately. By rendering them on your phone (where the WatchKit extension lives) and then transferring the view over bluetooth low energy links to the watch to display them would add a delay.
That reminds me of the cheap "MP4" players popular a few years ago (many of them iPod Nano clones...) that could play low-res video and had UI animations too - the animations were just a series of bitmaps and the video was basically MJPEG. The processor was a 24MHz Z80 with a few hundred KB (kilobytes) of RAM.
I also found this interesting: "(Dates & Timers) ... Does not need to be updated by your WatchKit extension". Makes me think of timer coalescing in OSX. Now they're just sidestepping the whole issue altogether.
Not necessarily timer coalescing and probably more of a radio optimization. All 3rd party code will run on the phone and not the watch, so any updates to the UI made via code will have to necessarily travel over Bluetooth.
Apple wants to limit the frequency of these updates, so the most frequently updated UI bits (clocks, timers) will be done on the device itself without the persistent BT use.
If you're talking about the use of pre-rendered animation - you may be right, but given the graphic effects when you're drawing in Digital Touch, it's probably got enough power for animations rendered on the fly. May be a matter of baby steps, and they'll eventually open up more of the hardware in a way that doesn't completely kill the battery.
From a quick glance at the docs I tend to agree with you. Seems like we're going to be working in a pretty restrained environment on the watch since Apple seems to prefer you do the heavy work on the phone & not the watch Here's to hoping that this is good news for the Apple Watch's battery life!
Based on development with the Pebble, processing doesn't seem to have much noticeable impact on watch battery life. Updating the screen, writing to flash, or doing communications use so much more battery than almost anything you can do on the CPU.
What is probably more constrained is the memory and storage available on the watch. By moving as much of the application to the phone as possible, they decrease the demands on the limited resources of the watch.
Create prerendered animations using a sequence of static images. Store canned animations in your Watch app bundle so that they can be presented quickly to the user. Canned animations also let you deliver high frame rates and smoother animations. Creating animations dynamically from your WatchKit extension and transferring them to Apple Watch adds a delay before playback can begin.
This is not a good sign as to the power of the watch, unless I'm drastically misinterpreting things.