Question

I’m debugging some performance issues in IE8 with RaphaelJS. We’re building graphs from ~1000 elements and text nodes in raphael and in particular one graph is causing us problems when it’s rendering. In IE9 it takes 2-7 seconds depending on the machine to render, and in IE8 1 minute plus.

You can see the website in question here. It’s the 3rd graph (click it).

Essentially we create elements for each point of data and draw them on the raphael canvas.

I’ve used the IE Developer Tools profiler and determined that it’s the setFillAndStroke() function called from both attr() and text() when we change the fill, stroke, style and a few other settings of elements. The getBoundingRect() function is the culprit in setFillAndStroke().

Here is a screenshot of the profiler output

In my research I’ve come across people having issues with IE8, attr() and text(), e.g.,

So a few questions:

1. Can you set a ‘default’ fill and stroke for Raphael elements so that they are created with that fill and stroke? This should remove the call to getClientBoundingRect(). I’ve tried looking for such a function in the docs but no luck.
2. Is this something we can solve without changing the look and feel of the graphs?
3. If this is something we can do just through the code, is it possible to do so without modifying RaphaelJS?
4. Any other ideas?

Someone seemed to have a similar problem in older versions of Raphael, apparently fixed in 2.0.0 but we’re using version 2.0.2 (tested to also have the same issue in 2.1.0).

Here is the issue report on github.

Answer 1

So thanks to Eliran Malka’s advice I was going ahead with changing from using attr() to adding classes and using CSS, when I found that we had a bug causing a total of 178 labels to be drawn instead of 8 (1 per 22~ intervals), all but the main 8 of them outside the dimensions of the ‘paper’.

Having a suspicion that getBoundingRect() was probably choking up when the elements were off screen, I found the source of the bug and fixed it, drawing only the expected 8, and all of them on canvas. This reduced load time from 1 minute plus to 8.8 seconds.

So the cause of the dramatic slowdown was using text() to create elements off screen, and then changing their attributes via attr().

While 8.8 seconds is still not great, it’s about an order of magnitude better than 1 minute and a bit (72~ seconds to be precise) so I’m going to call this ‘answered’ while we source the rest of the problems.