5 ms·

Apple Watch is encoding each frame as PNG

60 points by vzaliva 11y ago

userbinator 11y ago
Would you rather they use uncompressed bitmaps instead? I remember the little MP3/MP4 players which were very popular around a decade ago(https://en.wikipedia.org/wiki/S1_MP3_player https://en.wikipedia.org/wiki/S1_MP3_player ) used a similar strategy of making all the UIs bitmaps. The LCD had the windowing functionality built into its controller so it was easy to define a rectangular window and then just stream the appropriate pixels into it. They only had a 24MHz Z80 and 384KB of RAM, but hundreds of MB or more of secondary storage, so it made sense to tradeoff size for speed that way. You can see an example of that here: http://www.mympxplayer.org/pafiledb/images/screenshots/1208854267s1res.png http://www.mympxplayer.org/pafiledb/images/screenshots/12088...
Trisell 11y ago
I think I'm more impressed that LiveJournal is still around 10 years after it first came out.
- colinramsay 11y ago
  LiveJournal is older than that; it was launched in 1999.
- kiddico 11y ago
  It's the small accomplishments I appreciate.
- thought_alarm 11y ago
  10 years after it died, you mean.
herf 11y ago
PNG is not cheap on the compression side, due to the lossless coder. It's a little better to decompress: Some benchmarks on iPhone 6 are here: https://browser.primatelabs.com/geekbench3/4423501 https://browser.primatelabs.com/geekbench3/4423501 e.g., JPEG is 15x faster to compress and 2.5x faster to decompress.
- dietrichepp 11y ago
  You can always adjust the compression settings on a PNG to make compression faster.
donohoe 11y ago
The big take-away: In the end of the day, the watch battery is there just to shuffle these .PNGs around. When Apple realizes how to avoid that, the watch will last for a week instead of hours.
- DiabloD3 11y ago
  Except Android Wear watches are built essentially identically, and only get about a days worth of life, and don't do any of this crazy shit.
  - andrewaylett 11y ago
    Android Wear watches typically have the screen always on, and in the case of the OLED one (LG Urbane) I've got that means bright enough to see my way through a dark room. I usually wear mine overnight (with the screen off) for sleep tracking, and after 23h it's usually around 50%. I'd be quite happy suggesting you'd get two full days' use out of it, especially if you don't keep it awake all night.
  - nostrademons 11y ago
    Yeah. Pebble does get a week of battery life, however. The distinction between them and AppleWatch/AndroidWear is that the Pebble uses an E-ink screen that consumes no power when it doesn't change. That makes me think that the display is the biggest power drain on a smartwatch.
    - mavhc 11y ago
      It's not E-ink, it's a transflextive LCD
- megablast 11y ago
  This is ridiculous. Even if you don't use the screen the watch still only lasts less than 2 days.
- DannyBee 11y ago
  Except he provides no evidence this is true, and in fact, it's almost certainly 100% not true ;-) Hint: the power draw on these watches is not from drawing. On phones, with powerful CPU's, the display is usually 10x the draw of the CPU (depends on the CPU). On a watch, what do you think that ratio is?
dilap 11y ago
This is for 3rd party apps -- despite the "native" 2.0 SDK, where all your code runs on the watch, it's still split clumsily into app (which you can only control by providing interface templates) and extension, which is where your code runs. The extension can control the app only through a very limited SDK that has to do IPC to effect changes in the main app. Apple's own apps don't have this restriction, and I can't see a good one for 3rd party apps to have it, either -- hopefully they'll open up a full API in the future.
mrshoe 11y ago
I never understand how someone can write an article about their very first foray into something and then, at the end, assert that they know more than the experts already. > In the end of the day, the watch battery is there just to shuffle these .PNGs around. When Apple realizes how to avoid that, the watch will last for a week instead of hours. Drawing every frame using CoreGraphics is a terrible idea, on any iOS device. Just like any platform, you have to understand at least the basics of the underlying architecture if you want to write efficient code. I happened to make the built-in Stopwatch app on the watch, which displays an animated graph very similar to his. Suffice it to say, I did not use a CADisplayLink and CoreGraphics at 60fps. Especially considering my graph is horizontally scrollable by the user. Even if WatchKit still doesn't provide a more efficient way to do this (I don't know; I've never used WatchKit), rest assured that Apple's apps certainly don't use this method, so the week-long battery life claim is just a dream, unfortunately.
- dilap 11y ago
  Hi, 3rd party watch dev here! WatchKit is really limited. It would be impossible, I believe, to make an app anywhere near as good as the native Stopwatch using WatchKit. So this comment is pretty frustrating, actually: "you have to understand at least the basics of the underlying architecture if you want to write efficient code". What basic architecture? WatchKit is all we've got as a 3rd party devs! And it sucks. It seems insane and very ill-advised to me that Apple isn't using the same SDKs for their own apps as what's available to 3rd parties.
  - mrshoe 11y ago
    Your point is actually orthogonal to the OP's. The OP was claiming that Apple's architecture is flawed and that once they realize the error of their ways, battery life will improve dramatically. That's just not true. Your point is that the public SDK limits 3rd party developers from doing some stuff that Apple can do with the private SDK. That is, of course, absolutely true. Letting the public SDK (or at least parts of it) lag behind the private SDK, while certainly frustrating to 3rd party developers, is the right thing to do. The situation is exactly the same on the iPhone, iPad, and Apple TV. Apple has employed that strategy from the beginning with iOS, and they believe it to be the correct strategy, so they will almost certainly stick with it. I don't work at Apple any more (pushing toward launch on a startup!), but based on over 8 years of iOS history, I think it's safe to say that the public watch SDK will get more powerful over time, as private-only features are deemed ready to release to 3rd parties.
dietrichepp 11y ago
> When Apple realizes how to avoid that, the watch will last for a week instead of hours. In order for this statement to be true, the CPU would have to be using 85% of the entire watch's power consumption just to shuffle PNGs. I bet the entire CPU doesn't use nearly that much power, once you include the display.
i_s 11y ago
> Constants are defined via let, and variable are allowed to vary through a var. Though constants are lame, as only the binding itself is constant and you can change everything inside them as usual. That is at best misleading, as it is not true for collections. From the Swift docs: > If you create an array, a set, or a dictionary, and assign it to a variable, the collection that is created will be mutable. This means that you can change (or mutate) the collection after it is created by adding, removing, or changing items in the collection. If you assign an array, a set, or a dictionary to a constant, that collection is immutable, and its size and contents cannot be changed. Swift is the only language that I've seen that actually does make a distinction depending on the keyword used.
- krisdol 11y ago
  Rust does this as well, just FYI.
- Someone 11y ago
  It also is one of the only languages where collections are value types. And it has to, to make 'let' create truly immutable objects. Without them, this: var a = [1,2,3] let b = a a += [4,5,6] would change b.
- lionet 11y ago
  You are correct. But in FP, we understand immutability differently, so it becomes very painful to watch structural equivalence of the following variables: class Foo { var x = 0 } let a = [Foo(), Foo(), Foo()] var b = a a[0].x = 1 var c = b // [0].x == 1 ;( let d = a // [0].x == 1 ;(

60 points by vzaliva 11y ago

Would you rather they use uncompressed bitmaps instead? I remember the little MP3/MP4 players which were very popular around a decade ago(https://en.wikipedia.org/wiki/S1_MP3_player https://en.wikipedia.org/wiki/S1_MP3_player ) used a similar strategy of making all the UIs bitmaps. The LCD had the windowing functionality built into its controller so it was easy to define a rectangular window and then just stream the appropriate pixels into it. They only had a 24MHz Z80 and 384KB of RAM, but hundreds of MB or more of secondary storage, so it made sense to tradeoff size for speed that way. You can see an example of that here: http://www.mympxplayer.org/pafiledb/images/screenshots/1208854267s1res.png http://www.mympxplayer.org/pafiledb/images/screenshots/12088...

Trisell 11y ago

I think I'm more impressed that LiveJournal is still around 10 years after it first came out.

colinramsay 11y ago
LiveJournal is older than that; it was launched in 1999.
kiddico 11y ago
It's the small accomplishments I appreciate.
thought_alarm 11y ago
10 years after it died, you mean.

herf 11y ago

PNG is not cheap on the compression side, due to the lossless coder. It's a little better to decompress: Some benchmarks on iPhone 6 are here: https://browser.primatelabs.com/geekbench3/4423501 https://browser.primatelabs.com/geekbench3/4423501 e.g., JPEG is 15x faster to compress and 2.5x faster to decompress.

dietrichepp 11y ago
You can always adjust the compression settings on a PNG to make compression faster.

donohoe 11y ago

The big take-away: In the end of the day, the watch battery is there just to shuffle these .PNGs around. When Apple realizes how to avoid that, the watch will last for a week instead of hours.

DiabloD3 11y ago
Except Android Wear watches are built essentially identically, and only get about a days worth of life, and don't do any of this crazy shit.
- andrewaylett 11y ago
  Android Wear watches typically have the screen always on, and in the case of the OLED one (LG Urbane) I've got that means bright enough to see my way through a dark room. I usually wear mine overnight (with the screen off) for sleep tracking, and after 23h it's usually around 50%. I'd be quite happy suggesting you'd get two full days' use out of it, especially if you don't keep it awake all night.
- nostrademons 11y ago
  Yeah. Pebble does get a week of battery life, however. The distinction between them and AppleWatch/AndroidWear is that the Pebble uses an E-ink screen that consumes no power when it doesn't change. That makes me think that the display is the biggest power drain on a smartwatch.
  - mavhc 11y ago
    It's not E-ink, it's a transflextive LCD
megablast 11y ago
This is ridiculous. Even if you don't use the screen the watch still only lasts less than 2 days.
DannyBee 11y ago
Except he provides no evidence this is true, and in fact, it's almost certainly 100% not true ;-) Hint: the power draw on these watches is not from drawing. On phones, with powerful CPU's, the display is usually 10x the draw of the CPU (depends on the CPU). On a watch, what do you think that ratio is?

dilap 11y ago

This is for 3rd party apps -- despite the "native" 2.0 SDK, where all your code runs on the watch, it's still split clumsily into app (which you can only control by providing interface templates) and extension, which is where your code runs. The extension can control the app only through a very limited SDK that has to do IPC to effect changes in the main app. Apple's own apps don't have this restriction, and I can't see a good one for 3rd party apps to have it, either -- hopefully they'll open up a full API in the future.

mrshoe 11y ago

I never understand how someone can write an article about their very first foray into something and then, at the end, assert that they know more than the experts already. > In the end of the day, the watch battery is there just to shuffle these .PNGs around. When Apple realizes how to avoid that, the watch will last for a week instead of hours. Drawing every frame using CoreGraphics is a terrible idea, on any iOS device. Just like any platform, you have to understand at least the basics of the underlying architecture if you want to write efficient code. I happened to make the built-in Stopwatch app on the watch, which displays an animated graph very similar to his. Suffice it to say, I did not use a CADisplayLink and CoreGraphics at 60fps. Especially considering my graph is horizontally scrollable by the user. Even if WatchKit still doesn't provide a more efficient way to do this (I don't know; I've never used WatchKit), rest assured that Apple's apps certainly don't use this method, so the week-long battery life claim is just a dream, unfortunately.

dilap 11y ago
Hi, 3rd party watch dev here! WatchKit is really limited. It would be impossible, I believe, to make an app anywhere near as good as the native Stopwatch using WatchKit. So this comment is pretty frustrating, actually: "you have to understand at least the basics of the underlying architecture if you want to write efficient code". What basic architecture? WatchKit is all we've got as a 3rd party devs! And it sucks. It seems insane and very ill-advised to me that Apple isn't using the same SDKs for their own apps as what's available to 3rd parties.
- mrshoe 11y ago
  Your point is actually orthogonal to the OP's. The OP was claiming that Apple's architecture is flawed and that once they realize the error of their ways, battery life will improve dramatically. That's just not true. Your point is that the public SDK limits 3rd party developers from doing some stuff that Apple can do with the private SDK. That is, of course, absolutely true. Letting the public SDK (or at least parts of it) lag behind the private SDK, while certainly frustrating to 3rd party developers, is the right thing to do. The situation is exactly the same on the iPhone, iPad, and Apple TV. Apple has employed that strategy from the beginning with iOS, and they believe it to be the correct strategy, so they will almost certainly stick with it. I don't work at Apple any more (pushing toward launch on a startup!), but based on over 8 years of iOS history, I think it's safe to say that the public watch SDK will get more powerful over time, as private-only features are deemed ready to release to 3rd parties.

dietrichepp 11y ago

> When Apple realizes how to avoid that, the watch will last for a week instead of hours. In order for this statement to be true, the CPU would have to be using 85% of the entire watch's power consumption just to shuffle PNGs. I bet the entire CPU doesn't use nearly that much power, once you include the display.

i_s 11y ago

> Constants are defined via let, and variable are allowed to vary through a var. Though constants are lame, as only the binding itself is constant and you can change everything inside them as usual. That is at best misleading, as it is not true for collections. From the Swift docs: > If you create an array, a set, or a dictionary, and assign it to a variable, the collection that is created will be mutable. This means that you can change (or mutate) the collection after it is created by adding, removing, or changing items in the collection. If you assign an array, a set, or a dictionary to a constant, that collection is immutable, and its size and contents cannot be changed. Swift is the only language that I've seen that actually does make a distinction depending on the keyword used.

krisdol 11y ago
Rust does this as well, just FYI.
Someone 11y ago
It also is one of the only languages where collections are value types. And it has to, to make 'let' create truly immutable objects. Without them, this: var a = [1,2,3] let b = a a += [4,5,6] would change b.
lionet 11y ago
You are correct. But in FP, we understand immutability differently, so it becomes very painful to watch structural equivalence of the following variables: class Foo { var x = 0 } let a = [Foo(), Foo(), Foo()] var b = a a[0].x = 1 var c = b // [0].x == 1 ;( let d = a // [0].x == 1 ;(