RGBA colorscale support for surface traces

[lucapinello]

No description provided.

[archmoj]

cc: #4331

[etpinard]

@archmoj What's your take on this?

Sounds like we could both honour the alpha channel in colorscale[i] = [255, 0, 0, alpha] items AND implement opacityscale in surface traces? I worry about poor rendering performance, but it sounds like we could enable both.

[etpinard]

@lucapinello could you share the data and layout settings you used to generate this graph

from #4331 (comment)

[etpinard]

This PR essentially implements #4120

[archmoj]

Ranges needed for opacity can be very from those of color channels.
I'd vote for investing time on implementing opaityscale and possibly opacitybar.

[etpinard]

@archmoj ok if we rename this PR RGBA colorscale support for surface traces?

This implementation isn't per-element, it's per colorscale step item.

[archmoj]

@archmoj ok if we rename this PR RGBA colorscale support for surface traces?

This implementation isn't per-element, it's per colorscale step item.

Renamed. Thanks!

[lucapinello]

@etpinard sure thing: plotly/plotly.py#1859

[archmoj]

Closing this PR in regard to implementation of opacityscale in #4480.

[etpinard]

@archmoj I don't understand why you closed this PR.

To me it is a nice complement to opacityscale and it makes surface colorscale more on-par with other (mainly used for SVG traces) colorscales in the library.

[archmoj]

@etpinard you are right.
1st - I thought colorbar won't be rendered with transparent colors. But it looks OK e.g. this treemap demo appear to work!
2nd - We need to patch gl-surface and other gl-vis modules to enable transparency without alpha 0.99 hack.
I re-open this PR for now; but I suggest continue working on it after #4480 is merged.

[etpinard]

I re-open this PR for now; but I suggest continue working on it after #4480 is merged.

Yes, that's fine!

[archmoj]

Closing not that #5166 is open.