Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
LionelMarbot opened this issue Feb 5, 2016 · 6 comments
Closed
Labels

Comments

@LionelMarbot
Copy link

@LionelMarbot LionelMarbot commented Feb 5, 2016

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
Copy link
Collaborator

@TorsteinHonsi TorsteinHonsi commented Feb 9, 2016

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
Copy link
Author

@LionelMarbot LionelMarbot commented Aug 28, 2018

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

@KacperMadej
Copy link
Contributor

@KacperMadej KacperMadej commented Aug 29, 2018

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
Copy link

@BrianLaughlan BrianLaughlan commented Sep 11, 2018

@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
Copy link
Collaborator

@TorsteinHonsi TorsteinHonsi commented Sep 11, 2018

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

@TorsteinHonsi
Copy link
Collaborator

@TorsteinHonsi TorsteinHonsi commented Sep 12, 2018

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants