Hi, I found different messages on the internet about this bug on wearable watchface (or apps).
~0.1 second after the wake up of the screen animation freeze at the position BEFORE the app was hidden by screen off or by another widgets. And after that short period animation updated and everything goes in a right way. But this happen everytime the app goes in background and freground. It's really annoying and I can't publish my watchface without fixing that bug.
I found that trouble only in web versions of the code. Native watchface can handle wakeup well, without freezes and bugs. Even watchfaces from Tizen samples has the same bug: 'Basic Watch' from Web app section
And in other samples I cannot find specific feature that can avoid that bug. As far as I understand when the widget or watchface hidden it pause in order to prevent battery drain. But it does that so fast so even event listeners can't run itself in order to do their stuff, like visibility change and ambientmode change.
So even splitting calculation stuff for clock hands animations in another thread with help of Worker doesn't help at all.
So according to that document :
WRT MUST suspend JavaScript execution and rendering (including CSS animations) when the Web Application enters an invisible state, unless the Web Application has been explicitly declared to support the background support mode in its configuration file.
But backgroud support required to specify background-category, like: background-network, download, iot communication, location, media, sensor. And none of that fits for the animation update. I can't find obvious parameter that can fix that AWAKE bug.
Event listeners like 'pagebeforehide', 'pagebeforeshow', 'load', 'unload' can't fix that as well since it work inside the app, but when you slide to the left or to the right watchface disappeared and paused OUTSIDE of the app, even if I print screenX or screenY position of the finger it prints fixed value, like '45,45,45,45' during the left-right swipe. So none of that common Javascript event listeners can't help. I think there should be Tizen special event that can do that.
'setScreenStateChangeListener' can catch screen on and off states, but can't handle udpateTime. There is something with execution order, it can process Javascript stuff, but can't process 'tizen.time.getCurrentDateTime();' so the only one thing that I can do for that 0.1 sec. on wake up is a pure Javascript.
I've tried to add 'WebkitTransition' to 'all 0.1 ease-out' once it wake up and turn it off after that, just to check if it will fix that. Didn't help: this thasition is rough, unconsistent and noticeable.
The only thing that works is WebkitTransition = opacity 0.1. That transiton just hide that watch needles jumps. Which is not the SOLUTION, it's lust a COMPROMISE that hide that bug and delay watchface appearance.
I found info on that page that there is metadata: backgroundtick must fix that for both (Native and Web) apps, but looks like it's obsolete and doesn't work. Native app update ok now without that metadata and for web app it doesn't work at all in any format:
<tizen:metadata key="http://developer.samsung.com/tizen/metadata/backgroundtickupdate" value=""/>
<tizen:metadata key="backgroundtickupdate" value=""/>
<tizen:metadata key="http://developer.samsung.com/tizen/metadata/backgroundtickupdate" value="1"/>
<tizen:metadata key="backgroundtickupdate" value="1"/>
So even Native watchfaces with 2.3.1 Tizen version work without that bug in my Galaxy watch active with Tizen 4.0
It's a shame that Tizen developers didn't warn about that bug (limitation) on the first page of documentation, it's important user experience feature that ruine smoothness of usability.