Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
Description
Hi, and thank you for creating Plotly and Dash! We ran into a concerning bug with the treemap plots that is causing us problems.
Description
Certain small sectors in a treemap can become disappear entirely. Their visibility changes as the size of the treemap container changes (e.g. as the web browser is zoomed in / out). I don't think the treemap we are creating is especially unusual (it has less than 100 sectors).
This is a very severe problem for us, because we need to rely on the treemap being a faithful representation of the underlying data.
Screenshots/Video
Please see the GIF below (using the Python code shown in this post).
Notice the orange sector labelled#55 (and the purple and dark green sectors above it) that the cursor highlights. When the GIF begins (and the browser is zoomed to 100%), these sectors are visible. However, as we zoom the browser, they disappear and reappear.
I used Firefox's "Inspect Element" tool to examine the orange sector's SVG element. This demonstrates that, when#55 "disappears", it does not just become too small to see -- it becomescompletely invisible, as evidenced byitsd="..." attribute suddenly being set to"".
Steps to reproduce
Relevant Plotly / Dash versions
$ pip list| grep plotlyplotly 6.5.0plotly-cloud 0.1.0$ pip list| grep dashdash 3.3.0dash-bootstrap-components 2.0.4dash_cytoscape 1.0.2
Small example demonstrating the bug
#! /usr/bin/env python3importplotly.graph_objectsasgofromdashimportDash,dccnames= ['#1','#2','#3','#4','#5','#6','#7','#8','#9','#10','#11','#12','#13','#14','#15','#16','#17','#18','#19','#20','#21','#22','#23','#24','#25','#26','#27','#28','#29','#30','#31','#32','#33','#34','#35','#36','#37','#38','#39','#40','#41','#42','#43','#44','#45','#46','#47','#48','#49','#50','#51','#52','#53','#54','#55','#56 – 58 (28-node components)','#59 – 62 (27-node components)','#63 – 69 (26-node components)','#70 – 74 (25-node components)','#75 – 79 (24-node components)','#80 – 82 (23-node components)','#83 – 95 (22-node components)','#96 – 106 (21-node components)','#107 – 112 (20-node components)','#113 – 129 (19-node components)','#130 – 145 (18-node components)','#146 – 160 (17-node components)','#161 – 175 (16-node components)','#176 – 197 (15-node components)','#198 – 222 (14-node components)','#223 – 240 (13-node components)','#241 – 285 (12-node components)','#286 – 334 (11-node components)','#335 – 373 (10-node components)','#374 – 427 (9-node components)','#428 – 504 (8-node components)','#505 – 610 (7-node components)','#611 – 737 (6-node components)','#738 – 907 (5-node components)','#908 – 1,206 (4-node components)','#1,207 – 1,823 (3-node components)','#1,824 – 3,747 (2-node components)','#3,748 – 8,004 (1-node components)','Components']parents= ['Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','Components','']values= [6123,156,135,101,97,95,72,63,60,58,57,57,56,55,55,54,48,45,43,43,42,42,40,38,37,37,37,35,35,34,34,34,34,33,33,33,33,33,33,32,32,32,32,31,31,31,31,31,30,30,30,30,30,30,29,84,108,182,125,120,69,286,231,120,323,288,255,240,330,350,234,540,539,390,486,616,742,762,850,1196,1851,3848,4257,28064]# move some sectors (everything to the right of #55) to be children of a new sector named "Small Components"i=names.index("#55")forxinrange(i+1,len(names)-1):parents[x]="Small Components"num_in_small=sum(values[i+1:len(values)-1])values.insert(-1,num_in_small)names.insert(-1,"Small Components")parents.insert(-1,"Components")app=Dash()app.layout= [dcc.Graph(figure=go.Figure(go.Treemap(labels=names,parents=parents,values=values,branchvalues="total",sort=False ) ) )]app.run(debug=True)
Notes
This problem impacts both
px.treemapandgo.Treemap.This problem impacts both Firefox (v146.0) and Chromium (v143.0.7499.40).
The problem only seems to occur when we use
sort=Falsewhen creating the treemap. (However, maybe this is just because this changes the location of the small sectors? I suspect this problem is still possible to reproduce withoutsort=False.)The problem only seems to occur when the treemap has multiple layers -- that is, when we add the
Small Componentsrectangle above. If we don't do this, then these sectors can still get really small, but they can still at least be hovered over with the mouse.Looking through past bug reports, two things that seem relevant are[BUG] Data in
px.imshowdisappears at default zoom, reappears when zooming in with dense data #5209 andthis Plotly Forum post.If fixing the bug is not possible, it would at least be helpful for Plotly to somehow emit a warning that the treemap is not accurately rendering the data. I think it would be possible to write some Dash / JS code that scans through the SVG and flags any
d=""elements (and then warns the user if we find any), but hopefully that is unnecessary.