Large drop in performance when going from version 4.6.0 to 4.7.2
I just noticed that 4.7.2 was available but my small project using 4.6.0 is significantly slower when using 4.7.2 and Chrome Version 29.0.1547.76 m
4.6.0 http://jsfiddle.net/Robodude/myrfN/ http://www.youtube.com/watch?v=-hM2cTIJVgA
4.7.2 http://jsfiddle.net/Robodude/JE3m6/ http://www.youtube.com/watch?v=H4NuMXpxYgs
You might have to resize the jsfiddle 'Result' frame to get the canvas to draw.
Drag and canvas to scroll across the calendar. Notice the speed of the updates in each version.
hiya! One thing that changed form 4.6.0 to 4.7.2 is the way that nodes are rendered who have both a fill and stroke, and an opacity or shadow. Before 4.7.2, nodes with both a fill and stroke who also had an opacity or shadow were not rendered correctly due to the canvas spec. I.e., if you have a shape with both a fill and stroke, and an opacity was applied to the shape, you could see the fill beneath the stroke, because the canvas applies opacities to both the stroke and fill. v4.7.2 addresses this use case by rendering those shapes onto a buffer canvas, copying the result onto the scene canvas, and then applies an opacity to the whole shape. This means that performance will suffer a bit for those use cases.
Does your application have any shapes with both a fill and stroke, and also has an opacity or shadow applied? If so, you'll see much better performance if you remove one of these properties (stroke, opacity, or shadow). If not, you could use toImage() to cache a shape as image so that it doesn't have to be redrawn.
Thoughts?
Great, thanks for the response! The app does make heavy use of shadows and opacity so I'll start converting everything over to use toImage wherever I can.
Hi!
I am also trying to build somekind of calendar with KineticJS. It's beginning to work pretty decent. I have about 20 objects on the canvas with fill stroke opacity and shadow. In 4.7.0 (did not try 4.7.1) it all worked pretty fast.
Since 4.7.2 i think its about 10 to 20 times slower. In 4.7.0 it took a few seconds to render and since 4.7.2 its almost half a minute, and on top of that it all looks the same :) Could it be possible to look at it again or otherwise choose the new or the old rendering ?
Thanks for your time and for the great product you are making.
yes, Ill add a config option that enables "lazy opacity and shadows" to help boost performance, if the dev doesn't care about the stroke / fill problem with canvas. This will be added to v4.7.3
4.7.3 schedule: https://github.com/ericdrowell/KineticJS/wiki/Release-Schedule
Have I got this correct...
The problem occurs when a fill and stroke are applied, combined with either opacity or shadow? But if you only have a fill, then combining it with opacity or shadow is OK?
@villabolo that is correct. in v4.7.3, I'll add a config option that improves performance but degrades the rendering quality if so desired (essentailly making things render as they did before 4.7.2)
i.e., I was thinking of adding a new strokeShadowEnabled=false, which means that the shadow is only applied to the filled portion of a shape, which improves performance (this is the way shadows worked automatically in v4.7.1 and earlier).
Likewise, I may add another attribute that reduces opacity rendering quality for shapes with both a stroke and fill to further improve performance (as it was before v4.7.2)
Hi, I think that's a great idea.
In my example i have a very small stroke line and very little shadow, just to add some small effect. In this case you really can't see the difference, just the difference in performance. But i can imagine for other examples it makes a huge difference.
So if it is an option that can fit your needs that will be great.
@ericdrowell did these options make it into the 4.7.3 release? If not, when can we expect to see these attributes added?
Later this month. I released v4.7.3 early because there were a lot of pixel ratio issues that needed to be hot fixed.
https://github.com/ericdrowell/KineticJS/wiki/Release-Schedule
Thanks for the quick response! Keep up the great work.
Why is it taking so long to get this issue fixed? The config option promised for 4.7.3 is now scheduled for late June.
hey! what about this lazy options?
i do understand you whant to improve the code but, for a lot of people it was a regresion.
so please could you do something?