Hello,
I was wondering if anyone has already bumped into this problem:
basically, when the graph is showing real-time data with a lot of samples in a trace, let’s say around 1700 and mode set as markers or lines+markers, the tab starts suffering from the load until it get stuck.
This problem however, does not arise in the case that mode: lines is used.
Any idea/suggestion?
Thanks
That’s strange.
Would you mind sharing a reproducible example to help us debug?
I’ll briefly explain to you how my application works. I’m getting the traces via socket io as a raw buffer. Each trace contains more or less 144 samples and 144 timestamps. On the client side there is quite a lot of work to be done to transform this node js raw buffer into a data structure suitable for the newPlot function call. However, I don’t think that this is the main problem, because it works fine with lines.
Once all the parsing is completed I end up with an array of traces with at most 4 traces with this form:
“{
“x”: [
1519394219361,
1519394219362,
1519394219363,
1519394219364,
1519394219365,
1519394219367,
1519394219368,
1519394219369,
1519394219370,
1519394219372,
1519394219373,
1519394219374,
1519394219375,
1519394219377,
1519394219378,
1519394219379,
1519394219380,
1519394219381,
1519394219383,
1519394219384,
1519394219385,
1519394219386,
1519394219388,
1519394219389,
1519394219390,
1519394219391,
1519394219392,
1519394219394,
1519394219395,
1519394219396,
1519394219397,
1519394219399,
1519394219400,
1519394219401,
1519394219402,
1519394219404,
1519394219405,
1519394219406,
1519394219407,
1519394219408,
1519394219410,
1519394219411,
1519394219412,
1519394219413,
1519394219415,
1519394219416,
1519394219417,
1519394219418,
1519394219420,
1519394219421,
1519394219422,
1519394219423,
1519394219425,
1519394219426,
1519394219427,
1519394219428,
1519394219430,
1519394219431,
1519394219432,
1519394219433,
1519394219435,
1519394219436,
1519394219437,
1519394219438,
1519394219439,
1519394219441,
1519394219442,
1519394219443,
1519394219444,
1519394219446,
1519394219447,
1519394219448,
1519394219449,
1519394219451,
1519394219452,
1519394219453,
1519394219454,
1519394219456,
1519394219457,
1519394219458,
1519394219459
],
“y”: [
13495,
14512,
15617,
16826,
18131,
19522,
21002,
22539,
24172,
25835,
27520,
29225,
30960,
32673,
34403,
36139,
37860,
39554,
41190,
42778,
44292,
45762,
47137,
48425,
49641,
50765,
51773,
52656,
53413,
54049,
54560,
54945,
55197,
55315,
55283,
55123,
54818,
54381,
53816,
53118,
52285,
51348,
50283,
49138,
47873,
46530,
45100,
43602,
42021,
40396,
38726,
37011,
35261,
33495,
31731,
29970,
28218,
26504,
24833,
23192,
21611,
20098,
18661,
17317,
16016,
14846,
13793,
12862,
12058,
11360,
10798,
10369,
10078,
9923,
9897,
10031,
10285,
10683,
11204,
11849,
12635
],
“type”: “scatter”,
“name”: “Test1”,
“line”: {
“color”: “#e30883”
},
“visible”: true,
“mode”: “lines”,
“showlegend”: true,
“uid”: “7942dc”
}”
Obviously, my application keeps running because it works real-time, and so the graph si refreshed quite often.
Now, If I stop the application and I simply say data[0].mode=“markers” and then I update the graph with plotly.update it works fine even with 3000 samples. In this condition the browser sustains the load.
If however,I keep the application running and I set data[0].mode=“markers” using the console, the tab gets stuck only for cases where there are more than 1500 samples per trace. In the same condition, the problem does not happen when mode is set to “lines”.
I also checked the consumption of the the running tab with chrome task manager, and I can say that drawing markers increments the cpu usage of quite a bit.