Apple Watch is encoding each frame as PNG • Hacker News Board

Re: Apple Watch is encoding each frame as PNG

#21

Post by userbinator » Sat, Dec 05, 2015, 7:19 PM UTC

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 ) 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/12088...

Re: Apple Watch is encoding each frame as PNG

#22

Post by dilap » Sat, Dec 05, 2015, 7:28 PM UTC

mrshoe wrote: post #9

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 dev…

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.

Re: Apple Watch is encoding each frame as PNG

#23

Post by jfaat » Sat, Dec 05, 2015, 7:28 PM UTC

mynegation wrote: post #19

primitivesuave wrote: post #16

Earlier quoted context omitted.

I too was expecting a technical article from an expert, so I closed it after reading the first sentence. While reading the first sentence, a Flash plugin on the page crashed my browser, making the author even less credible of an authority on performance benchmarking.

It is a hosted blogging service and author has no power over what they do with the flash

The author has power over their choice of blogging platform though

Re: Apple Watch is encoding each frame as PNG

#24

Post by DannyBee » Sat, Dec 05, 2015, 7:29 PM UTC

exabrial wrote: post #18

DannyBee wrote: post #17

Earlier quoted context omitted.

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?

I have this weird feeling his statement might have been a joke, rather than to be taken literally as an engineering calculation. Nawh, I'm probably wrong.

As a joke, it's stupid.

Because it is basically "look at these idiots drawing pngs".

Except they aren't idiots, because if it worked, helped them develop faster, and doesn't actually matter, it's actually probably the right thing to do.

So it just makes him look ignorant.

Re: Apple Watch is encoding each frame as PNG

#25

Post by monochromatic » Sat, Dec 05, 2015, 7:30 PM UTC

exabrial wrote: post #18

DannyBee wrote: post #17

Earlier quoted context omitted.

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?

I have this weird feeling his statement might have been a joke, rather than to be taken literally as an engineering calculation. Nawh, I'm probably wrong.

Jokes are funny when they contain an element of truth. There's a difference between hyperbole and being wrong.

Re: Apple Watch is encoding each frame as PNG

#26

Post by andrewaylett » Sat, Dec 05, 2015, 7:40 PM UTC

DiabloD3 wrote: post #10

donohoe wrote: post #7

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.

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.

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.

Re: Apple Watch is encoding each frame as PNG

#27

Post by mrshoe » Sat, Dec 05, 2015, 8:05 PM UTC

dilap wrote: post #22

mrshoe wrote: post #9

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 dev…

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…

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.

Re: Apple Watch is encoding each frame as PNG

#28

Post by krisdol » Sat, Dec 05, 2015, 8:44 PM UTC

i_s wrote: post #15

> 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 mean…

Rust does this as well, just FYI.

Re: Apple Watch is encoding each frame as PNG

#29

Post by Someone » Sat, Dec 05, 2015, 8:51 PM UTC

i_s wrote: post #15

> 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 mean…

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.

Re: Apple Watch is encoding each frame as PNG

#30

Post by dilap » Sun, Dec 06, 2015, 12:31 AM UTC

mrshoe wrote: post #27

dilap wrote: post #22

Earlier quoted context omitted.

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…

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…

Yeah, OP's claims about battery life are manifestly silly. The HN headline makes it sound like the article is making claims about the Watch in general, but it isn't, just that one dev's app.

I understand and take your point about public APIs lagging behind private ones, but in this case it's not that the public SDK is lagging, it's a totally different beast.

The fundamental execution model is the same as watchos 1 -- you don't get to write code that runs in the app process, you write code that runs in a separate extension process and get to twiddle ui elements in the main process using a very limited API.

Which is why if you're trying to do anything dynamic, you have to resort to generating and beaming over images.

Besides this fundamental limitation, the management of app process vs extension process vs network daemons is still buggy (contributed to, probably, by the fact that apple isn't dogfooding), which means it's hard to impossible to make your app stable. I think this has been a huge contributor the general perception that 3rd party Watch apps are slow and buggy.

Obviously, I can only speculate about Apple's motives for going with WatchKit vs exposing native development, as on the iPhone.

My guess is they were very worried about an initial public perception of the watch being "battery life sucks," so they didn't want to open up 3rd party code to run on the Watch. Hence WatchKit and OS1.

Then there was a huge public negative perception about not having native apps, so they rushed out OS2, which has 'native' apps, but still following the (now nonsensical) 2-process model of WatchKit.

I do hope Apple opens up true native dev on the watch at some point.

It won't be "the public SDK getting more powerful over time," though, it will be making a qualitative change to the SDK itself.

P.S. If you haven't and are curious, I encourage you to take a look at WatchKit. I think you will be surprised at how limited it is.

P.P.S. I think Apple may have been better served by doing something akin to the original iPhone model -- just saying, "no 3rd party apps yet, but it's coming," rather than having a half-assed SDK on day 1.