Hi all,
I noticed a significant performance drop of the canvas redraw from version 1.14.3 to 1.14.6 and 1.15
I am by no means an expert when it comes to optimizing html canvas code. But my non optimized code worked almost flickr free in 1.14.3 whereas in higher versions it starts to flickr massively.
Btw. is there a way to double buffer the canvas? I tried to create a second canvas like I would in html but did not succeed.
Thanks and have a nice weekend
Flickering is necessarily not a sign of performance loss. What changed is that some actions are not performed synchronously anymore to actually optimise rendering performances, which sometimes introduces a frame of delay before the actual drawing. Flickering may happen on some circumstances (when widgets are edited or recreated because a non-dynamic property is changed) I consider acceptable, but if you find a case that you think should be considered as a bug, please provide details.
There is however a case of flickering that could be avoided (when widgets are recreated because a non-dynamic property is changed), I'm working on it (edit: should be fixed in next release).
Thanks for your reply Jean. I did not intend to say the new code contains a bug; the canvas widget is a blessing 
. I just noticed the different behaviour. You‘re absolutely right, flickering, does not necessarily mean lesser performance. It was a simplification.
Anyway, what I do is creating a note grid -like in a DAW- which involves drawing rectangles via a loop with different fill styles. Since switching fill styles is expensive afaik, this might be one reason. I think I‘ll try to optimise the code and see again.
I had another look at the behaviour in version 1.15
Some (but not all ) of my canvas widgets are based on the value of a fader, which determines the vertical offset of the drawing inside the canvas. The onDraw script of the canvas widgets get the value of the slider with the "get" function. e.g.:
var offset = get("verticalOffsetFader")
If I move the slider fast, all canvas widgets are cleared and only redrawn, when I stop moving the slider. This holds true even for the canvas widgets, which don not use the value of the fader at all! This is different from version 1.14.3 It looks like in version 1.14.3 the canvas widgets are drawn asynchroniously, whereas in version 1.15 all canvas widgets are redrawn synchroniously, refardless if value changed or not.
What is even more strange (in both versions): there is one canvas widget which uses the slider value which gets not automatically cleared and updated when I move the slider! I have to update this canvas widget by sending a dummy value to the widget. I cannot spot a difference between this widget and the other ones which might trigger this different behaviour.
I would like to provide you with some code, but there are lots of dependencies to my costum module which itself is heavily dependant on the data it gets from Ableton Live. I would have to create a stripped down 'stand alone' version.
Hopefully this explanation is helpfull
I'm not sure to understand the issue, could you please create a minimal session to demonstrate it ?
The drawing process did not change that much actually, it's only when the widget is recreated that things are a bit different (and flickery, but not anymore in upcoming version). Make sure you're not forcing the recreation of these widgets each time the fader updates (this would happen for example if you wrote something like @{fader_id} in a non-dynamic property).
What is even more strange (in both versions): there is one canvas widget which uses the slider value which gets not automatically cleared and updated when I move the slider!
That's the expected behavior, the canvas widget gets redrawn only when touched, when receiving a value, or at a periodic rate if continuous is true, there is no subscription mechanism behind functions such as get(). That being said I've been thinking to add a function to manually trigger a redraw from another widget's script (for instance from the fader's onValue script).
Thanks for clarifying. That is what thought (and hoped for). I‘ll check again if I have some @ statements or calls from the custom module.
I will see if I can create a demo version, showing the behaviour.
A console.log() call in the canvas' onCreate script would confirm whether its recreated or not.
Hello Jean,
thanks for your explanation. That helped a lot.
It was a nasty problem, since from my experiments with the canvas I had left over one @{} in a line that was commented. I was not aware, that commented lines in the script are still evaluated.
It was not easy to spot, since the lines are greyed out and hard to read. In my desperation I searched the text for "@" and viola...
Thanks a lot and have a nice sunday
Hey I'm glad to hear that ! Yes, the advanced syntaxes are parsed/resolved before the script compilation so there's no notion of comment when it happens.