Is there a list of devices that support onPartialUpdate?

I am poking around onPartialUpdate in a test watchface project. I am going watch model by model in the simulator and I am yet to find one that supports it (though I am checking AMOLED devices only). The code is:

  var yes = (Toybox.WatchUi.WatchFace has :onPartialUpdate);
System.println(yes ? "Has it" : "Doesn't have it");

Building with the SDK 7.2.1.

I've gotta be missing something obvious here... is that that it's not supported on AMOLED watches?

  • Interesting, thanks!

    So basically the real reason that AMOLED doesn't support onPartialUpdate() is because it can't be updated quickly enough for Garmin's liking. Garmin is trying to save battery life by limiting the execution time of the updates, and it's not necessarily the case that changing the pixels on an AMOLED display is the battery life issue here.

  • At one of the summits, DCR mentioned the "1hz/seconds all the time" feature and there was applause, Then alphamonkey took the stage and mentioned the 30ms, and there some unhappy faces. (recall this was pre AMOLED).  As it's by rows, with an analog WF, there are peaks at 12 and 6, and valleys at 3 and 9 (you can see this in the sim with an analog watch face for a MIP device in low power that uses onPartialUpdate with watch face diagnostics.

    And there are things you can't do in onPartialUpdate, like load resources (things that hit to the file system) and using them disables onPartialUpdate.

    And there are interesting things if you set two or more clip regions, say one near the top and another near the bottom. The screen refresh is the very top row to the very bottom row which again can make the 30ms a bit of a challenge

    The reason for only updating a limited area of the screen with onPartialUpdate, is really tied back to the 30ms average.  With that average being over a minute, so on an analog WF, it may be over 30ms near 12 and 6, but under 30ms at 3 and 9

  • There's also the CPU usage when the system has to call your callback function every second

  • There's also the CPU usage when the system has to call your callback function every second

    Yes but the question is: why can MIP devices support onPartialUpdate but not AMOLED devices? Not: why does always active mode consume more power in general?

    Obviously, regardless of the display type, onPartialUpdate() would have to be called once per second. (Or 59 times per minute).

    According to jim_m_58's answer, the custom row-addressable MIP hardware can be updated more efficiently than the older MIP displays or any AMOLED display (in terms of CPU usage).

    I have to admit this sounds more plausible than:

    - to avoid burn-in. (assuming the existing 10% pixel / brightness restriction still had to be followed)

    - to save energy used by the display itself. here I'm assuming that the difference is negligible between the power drawn by an AMOLED display with a static image and the power drawn by an AMOLED display with an image that changes slightly every second. I could be wrong tho. Intuitively, the latter situation would seem to draw *some* additional power, but the question is how much?

    So what I'm understanding from jim_m_58's answer is that if a row-addressable AMOLED display existed, then it would be possible might be possible to implement always active / 1 Hz mode, just like MIP. (Except that the higher resolution of AMOLED displays might still be a barrier, since you'd have more rows to update.)

  • So basically the real reason that AMOLED doesn't support onPartialUpdate() is because it can't be updated quickly enough for Garmin's liking

    This has gotta be then the overhead (or a limitation) of the Monkey C VM. Because there are high FPS animations in stock watch faces, apps and what not. In particular, there are circular wave-y animation that touches every pixels in a 10-15px rings around the screen's border. The AMOLED update speed is certainly not an issue *there*.

  • So basically the real reason that AMOLED doesn't support onPartialUpdate() is because it can't be updated quickly enough for Garmin's liking

    This has gotta be then the overhead (or a limitation) of the Monkey C VM. Because there are high FPS animations in stock watch faces, apps and what not. In particular, there are circular wave-y animation that touches every pixels in a 10-15px rings around the screen's border. The AMOLED update speed is certainly not an issue *there*.

    Yeah idk. Those animation are temporary tho. They don't run continuously. There's no native AMOLED watchfaces that show seconds (or live HR) *all the time*, unlike native MIP watchfaces, right? So in the case of MIP, CIQ onPartialUpdate() isn't doing anything a native watchface couldn't do. If onPartialUpdate() existed on AMOLED, then an AMOLED CIQ watchface could do something that a native watchface could not do: display live seconds or HR all the time.

    Instead of saying "updated quickly enough", I probably should've said that Garmin wants to minimize the average amount of CPU time spent updating the display (hence the 30 ms limit jim_m_58 referenced.) It could very well be that the AMOLED display can physically update quickly enough (it clearly has a higher refresh rate than MIP), but Garmin doesn't like the amount of CPU time that's necessary to transmit those updates. I think that's jim_m_58 meant, and that's what I was trying to convey.

    After all, as you pointed out, the real reason here can't be to avoid burn-in. Can it? Changing small parts of the screen can only mitigate burn-in, not cause burn-in, as you said.

    I'm just taking his comment at face value since he knows more about this stuff than I do. I was well aware of the fact that old MIP devices did not support 1 Hz updates / always active mode and newer MIP hardware was required for that support, but I didn't think AMOLED displays would have the same limitation. I never saw anything explicit about row-addressable MIP displays from Garmin, so I'm taking jim_m_58's word for it. (Maybe it was mentioned during a summit idk.)

  • Also, another way to check for onPartialUpdate() support, without running code in the sim and without reading the docs, is to search for symbol="onPartialUpdate" in ./Devices/**/*.debug.xml, at the CIQ root folder (.../Garmin/ConnectIQ).

    You could use this technique for other symbols, which might be helpful in the rare case that the docs aren't up-to-date or contain errors.

  • The specialized display was talked about back when this was first announced a number of years ago - people wanted to know if older devices would be supported, etc.

  • The specialized display was talked about back when this was first announced a number of years ago - people wanted to know if older devices would be supported, etc.

    Yeah, I gathered that but is there a reference that we can look at now? For those of us who are curious? I wanna hear about the custom row-addressable MIP display from the horse's mouth. Not that I don't believe you, but official sources are always nice, as they usually have details and insights that the rest of us aren't privy to or that we may have forgotten. I also don't think that important or interesting knowledge should be locked in the head of any one forum poster or confined to the forums at all.

    This goes back to the other discussion about how maybe old CIQ videos shouldn't be deleted.

  • I'm sure there are posts here in the forum. I recall Brian being one of the people to talk about it.

    Maybe there's something in the doc, but it's been years since I even looked for it, and the doc has also been reorganized since then.