Adding VML during stroke() takes a really long time

[GoogleCodeExporter]

An application that animates a canvas suffers greatly whenever stroke() is 
called. Using a JS profiler 
I was able to determine that the great majority of the time spent in stroke() 
is adding the VML to the 
element_.

For an animation that only calls stroke() once per loop, this isn't that big of 
a deal. However, an 
animation that composes the scene with lots of paths and calls to stroke is 
pretty much 
unwatchable due to the problems with adding VML rapidly to a document.

The VML items should be cached into a display list and rendered on a timely 
basis, rather than 
immediately during stroke(). This design would improve the performance of 
complex animations as 
well as reduce the CPU usage for the app itself.

Original issue reported on code.google.com by mbis...@gmail.com on 20 Dec 2009 at 6:47

[GoogleCodeExporter]

Attached is a patch with a display list that is rendered at 24 fps.

Original comment by mbis...@gmail.com on 20 Dec 2009 at 6:49

Attachments:

• drawTimer.patch

[GoogleCodeExporter]

DOM manipulation is very slow in IE, so, yes, this could be a special mode for 
ExCanvas, that could be specified as an option of the initElement method of the 
lib.

Original comment by fabien.menager on 21 Dec 2009 at 3:05

[GoogleCodeExporter]

I fixed a bug in my change that would clear the scene if more drawing was 
executed after the draw timer fired, 
but without a clear() call in between. In other words, the draw timer would 
always clear the scene before 
rendering. This broke apps that would draw a bit, then draw more, without 
clearing.

Original comment by mbis...@gmail.com on 15 Jan 2010 at 12:37

Attachments:

• drawTimer.patch

[GoogleCodeExporter]

This should be considered a standard implementation rather than some special 
mode. It is considerably faster 
and more efficient than the current design.

For those interested in trying it out, I have attached the patched version to 
this comment.

Original comment by mbis...@gmail.com on 15 Jan 2010 at 12:39

Attachments:

• excanvas.js

[GoogleCodeExporter]

This is a good idea but I don't like making drawing async since it leads to 
flickery 
UI. We could suspend drawing in ctx.save and resume it in ctx.resume?

Original comment by erik.arv...@gmail.com on 21 Mar 2010 at 12:19

[GoogleCodeExporter]

About an async problem, do you have an example I can look at? Theoretically it 
shouldn't be an issue as the draw 
timer has to wait for the execution thread to operate; if the thread is busy 
painting a scene, it won't be 
interrupted by the timer to render it.  The entire scene will be completed 
before the timer fires to push it into 
VML.

One issue with using save/restore exclusively is that one is not required to 
call restore() after a save(), which 
means the render wouldn't occur, or would render some time later when another 
render is executed.

Original comment by mbis...@gmail.com on 22 Mar 2010 at 6:20

[GoogleCodeExporter]

I have updated the patch to r73, which includes the text drawing changes since 
r3.
All the tests in testcases pass.

Original comment by mbis...@gmail.com on 2 Apr 2010 at 2:01

Attachments:

• drawTimer.patch

[GoogleCodeExporter]

Here is the patched excanvas.js if you want to try it out.

Original comment by mbis...@gmail.com on 2 Apr 2010 at 2:02

Attachments:

• excanvas.js

[GoogleCodeExporter]

Makes everything perform, thanks for this wonderful patch

Original comment by sebastia...@gmail.com on 20 Jul 2012 at 12:20