About bindings:
About bindings:
If you bind a ‘hard’ feature like (icon) colorize, when it changes, the container scrolling becomes unresponsive, and other bindings refresh slower.
This is really noticeable if you bind this to the colorize
Color.HSVToColor([animate(“$ll_second”)/60*360,1,1])
And question: is the ‘dummy’ feature suitable for tests and clocks that doesn’t need to change anything about the item? Does it needs a return? I found the answer in the wiki
« Playing with Bindings for battery level (Previous Post)
(Next Post) I got LL sideloaded on my android wear. »
< ![CDATA[
Another thing.
If LL is paused, when you resume it the animate function returns the whole difference between the previous value and the next.
With the blink effect from the wiki page: when you resume after a long period of time, the item blinks very fast.
Is it possible, if not I’m suggesting it, to set a parameter to the animate function so that it ‘forgets’ the non-sent values?
Also, all this values are sent after a value change, so if you are making the clock of the video, the minute arrow will move only when the minute changes, and will do all the non-update values.
So I think the best will be, with animate, an option to automatically send the new value after resume and animate the others
]]>
< ![CDATA[
The issue is that the colorize parameters is expensive. It needs to reload the original image from persistent storage and apply a filter. It cannot be efficient enough to be animated.
Pause/resume should work as expected, there is probably something I overlooked here… I confirm that changes shouldn’t be stacked this way, I don’t even know how this is possible, lol!
]]>
< ![CDATA[
About the colorize: maybe you should say that in the binding wiki page? (Sorry if it is, I didn’t found it but maybe I missed it)
]]>
< ![CDATA[
Regarding the fast blinking, there is a big issue with transparency, it will not animate correctly at all in this version.
Also crossing minutes will behave badly because of the negative step from 59 to 0, I think this is the cause for the fast blink.In some situations a timestamp would be better. I will add this to the list of date/time variables.
]]>