Chart having a category with a very (!) long name takes minutes to load

[LionelMarbot]

Hi,

Here is a chart with a relatively long category name: http://jsfiddle.net/fnhktf82/
No problem, everything works fine.

Here is the same chart, just with an even longer category name: http://jsfiddle.net/fnhktf82/2/
Takes minutes to load, in every browser we tested.

It seems to happen, when a certain length is hit.

Any ideas?

Best,
Lionel

[TorsteinHonsi]

It seems like problem in the buildText method, where the number of iterations grows exponentially as the number of words increase. We have experimented with a faster way of breaking text, but this work is still inly experimantal.

The best workaround for now is that your setup makes sure to not pass that long texts to the categories.

[LionelMarbot]

Is there any update on this? We are still facing this issue in v6.1.1.

[KacperMadej]

Hi @LionelMarbot

As a workaround you could set useHTML for axis labels to true.

The problem: ~5 seconds to render
http://jsfiddle.net/BlackLabel/grfvadp7/

The workaround: <0.2 seconds to render
http://jsfiddle.net/BlackLabel/grfvadp7/1/

[BrianLaughlan]

@KacperMadej I tried to use your workaround with useHTML set to true, this causes more problems for me than it solves.

Yes, using that option fixes the drawing bug, but it leaves me with a not so useful html label that does not have the "built in" highcharts ellipsis etc. I tried to use CSS ellipsis, but it is not working properly.

Overflow and label positions are not calculated well (at all?) with HTML labels, you can even see this in your example: https://doc.enuvo.ch/40ac1dc7b2.png

Could someone at Highcharts please give any indication of when this drawing bug might be fixed?

[TorsteinHonsi]

I'm working on this now, implementing a binary search for line wraps instead of the ineffective linear search. Expecting results tomorrow.

[TorsteinHonsi]

The commits above improve the performance of multiline text in two ways:

• Instead of a linear search for the amount of words that fit into a line, it now runs a binary search. Also, redundant code was removed since this could be combined with the way a string is truncated to apply ellipsis.
• Instead of adding tspans to the text node and running getBBox, add the whole text string, run getSubStringLength as a binary search, then update the tspan with the resulting text length. This way, the tspan is populated only twice for each line, and the appropriate line length is identified by the fast getSubStringLength function. The dead slow getBBox function doesn't run at all.

Results

• The original post's jsFiddle previously rendered in 63 seconds in Chrome. It now renders in 290 milliseconds.
• Kacper's 5-second chart rendered for me in 2400 milliseconds in Chrome. Now it takes 120.
• In Firefox the improvement is greater. It was slower than Chrome before the changes, but now it is on par.
• Safari is generally slower but the relative improvement the same as Chrome.
• In Edge, Kacper's test goes from 13.7 seconds to 670 ms.