
Apple Watch is encoding each frame as PNG - vzaliva
http://lionet.livejournal.com/137350.html
======
mrshoe
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
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
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.

~~~
dilap
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.

~~~
dilap
Actually, thinking about it, they are doing something akin to the iPhone model
-- initially iPhone development was supposed to be done as html+js web apps,
and devs revolted, and then we got a real SDK.

WatchKit is the html+js of WatchOS development. OK, not that bad, but the
situation is analogous.

~~~
mrshoe
I was going to reply to you and say the same thing: it's extremely similar to
the initial iPhone 3rd party developer story, and for the same reasons. Apple
is pretty predictable, really.

I know how WatchKit works, I was in on some of those meetings... Trust me,
everyone at Apple had the same concerns you expressed and they still do. It
will get better over time.

Also note that some built-in Apple apps _do_ use WatchKit.

And I would still argue that allowing 3rd party code to run on the watch
instead of in an extension on the phone would be just another example of an
internal-only feature being opened up to the public. It's the same pattern. I
realize that's a significant "feature", but so was the switch from html+js to
native apps on the phone. And those significant advances go through the same
decision process as smaller ones: do we feel comfortable opening up this
feature to 3rd parties? what are the risks? have we used it enough internally
to feel confident? has it iterated enough internally that we consider it
stable enough to release (because it's hard to change after release)? etc.

------
i_s
> 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.

~~~
Someone
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.

------
dietrichepp
> 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.

------
dilap
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.

------
userbinator
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/12088...](http://www.mympxplayer.org/pafiledb/images/screenshots/1208854267s1res.png)

------
herf
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
You can always adjust the compression settings on a PNG to make compression
faster.

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

~~~
colinramsay
LiveJournal is older than that; it was launched in 1999.

------
donohoe
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
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.

~~~
nostrademons
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
It's not E-ink, it's a transflextive LCD

