You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Small bug - sometimes, depending on the layout's height/vertical margins, one of the colorbar's .cbfill will get drawn outside the outline (see http://codepen.io/hellochar/pen/JREjyv):
When yanchor: 'bottom' is used it is off by far more pixels also overlapping with mode bar. So this mode is pretty much not usable at the moment. It should simply set y=0 on this mode.
Looks like the original issue is masked in v1.29.0 - I suspect the tweaks in #1854 result in the outline covering the out-of-place bar - but there's still a y="-1" bar sometimes so I suspect it could become visible in certain cases. Frankly the whole concept of constructing our colorbars from 256 overlapping bars (regardless of how many pixels tall the bar is) seems a bit silly, I'm going to try to replace it with a simple gradient fill.
A somewhat urgent aspect of this: lines in the colorbar with the default width of 0.5 just started to disappear for me:
This only seems to be happening in Chrome on mac on my non-retina second screen. (I can't reproduce this even in ostensibly the same version of chrome on browserstack...) The lines still appear on my retina screen, and in other browsers. And they reappear if I give the lines any tilt away from horizontal, a somewhat different alignment relative to the edge of a pixel, or a width > 0.5px (even 0.51px). Another overly eager optimization by chrome? Or perhaps it somehow came in with the latest Mac OS update that I installed this morning? I don't think chrome updated in the last few days, and I'm quit confident this looked fine at the end of last week for me.
Good to know. Just wanted to be 100% sure we were all looking at identically the same code. I have a non-retina screen back at home that I can check out tonight. Anyone else able to confirm?
possibly - crispEdges is what I was going to do to fix the other part of this anyway - just worried that this will lead to other instances where the line gets completely deleted too - typically that's even easier to do crisp than non-crisp.
My chrome just updated from v59 to v60 and these artifacts (along with a bunch of related antialiasing failures I've noticed) seem to have been fixed. So the y="-1" issue and crisp rendering change are still open but unless other people report these missing lines and other failures I think this is no longer urgent.
@andi1984 I haven't been able to reproduce the yanchor: 'bottom' issue you mentioned. Maybe it was solved somewhere else, or maybe I just haven't found the other pieces required to exhibit it... if you still see this please open a new issue with a reproducible example.
Activity
etpinard commentedon Sep 22, 2016
Thanks for the report.
andi1984 commentedon Jan 5, 2017
When
yanchor: 'bottom'is used it is off by far more pixels also overlapping with mode bar. So this mode is pretty much not usable at the moment. It should simply sety=0on this mode.alexcjohnson commentedon Jul 24, 2017
@etpinard pointed out this issue when I mentioned a related one during #1906, so I might as well combine them and tackle them simultaneously:
alexcjohnson commentedon Jul 24, 2017
Looks like the original issue is masked in v1.29.0 - I suspect the tweaks in #1854 result in the outline covering the out-of-place bar - but there's still a
y="-1"bar sometimes so I suspect it could become visible in certain cases. Frankly the whole concept of constructing our colorbars from 256 overlapping bars (regardless of how many pixels tall the bar is) seems a bit silly, I'm going to try to replace it with a simple gradient fill.alexcjohnson commentedon Jul 24, 2017
A somewhat urgent aspect of this: lines in the colorbar with the default width of 0.5 just started to disappear for me:

This only seems to be happening in Chrome on mac on my non-retina second screen. (I can't reproduce this even in ostensibly the same version of chrome on browserstack...) The lines still appear on my retina screen, and in other browsers. And they reappear if I give the lines any tilt away from horizontal, a somewhat different alignment relative to the edge of a pixel, or a width > 0.5px (even 0.51px). Another overly eager optimization by chrome? Or perhaps it somehow came in with the latest Mac OS update that I installed this morning? I don't think chrome updated in the last few days, and I'm quit confident this looked fine at the end of last week for me.
rreusser commentedon Jul 24, 2017
@alexcjohnson This page: https://rreusser.github.io/plotly-mock-viewer/#contour_heatmap_coloring
Shows this for me (albeit on a retina screen):
What do you see? Chrome doesn't appear to have just updated for me.
alexcjohnson commentedon Jul 24, 2017
@rreusser Yep, I see the missing lines there too.
rreusser commentedon Jul 24, 2017
Good to know. Just wanted to be 100% sure we were all looking at identically the same code. I have a non-retina screen back at home that I can check out tonight. Anyone else able to confirm?
rreusser commentedon Jul 24, 2017
Solves it, of course, but not a solution…
alexcjohnson commentedon Jul 24, 2017
possibly -
crispEdgesis what I was going to do to fix the other part of this anyway - just worried that this will lead to other instances where the line gets completely deleted too - typically that's even easier to do crisp than non-crisp.alexcjohnson commentedon Jul 25, 2017
My chrome just updated from v59 to v60 and these artifacts (along with a bunch of related antialiasing failures I've noticed) seem to have been fixed. So the
y="-1"issue and crisp rendering change are still open but unless other people report these missing lines and other failures I think this is no longer urgent.etpinard commentedon Aug 15, 2018
Accidently automatically close by #2891
Github isn't smart enough yet to know that would probably make it easier to finally close isn't equivalent to close.
alexcjohnson commentedon Aug 15, 2018
Hah, maybe I should take that as a sign and just do ^^
fix the underlying problem that led to #970
alexcjohnson commentedon Aug 16, 2018
@andi1984 I haven't been able to reproduce the
yanchor: 'bottom'issue you mentioned. Maybe it was solved somewhere else, or maybe I just haven't found the other pieces required to exhibit it... if you still see this please open a new issue with a reproducible example.