Image flickering when the y-axes is *not* reversed

[almarklein]

The Image trace is quite efficient when a base64-encoded png is used as the source. However, when the current implementation (of the Image trace in Plotly) needs extra steps (including per-pixel blitting) when the image is not aligned with the screen.

Possible solutions:

• Improve the canvas rendering itself (if possible): https://github.com/plotly/plotly.js/blob/master/src/traces/image/plot.js
• Maybe we can use glheatmap if our datatransfer can be made fast enough to not need base64-png. -> Nope, see Add script to check performance #23

[emmanuelle]

I'm not sure I understand all what you wrote, could you please give more details or an example? That said, I remember that for the Image trace the fast image rendering (passing the b64 string directly to the browser) is only performed when the axis is reversed (default case) that is when the origin is represented at the top-left corner. See https://github.com/plotly/plotly.js/blob/master/src/traces/image/plot.js#L18 and https://github.com/plotly/plotly.js/blob/master/src/traces/image/plot.js#L34 (maybe you had already seen this). @antoinerg implemented both the Image trace and the fast image rendering so he's the person to ping for this kind of questions :-).

What is the usecase where we're not happy with a not-reversed y-axis?

[almarklein]

Well, the VolumeSlicer has a reverse_y argument, because sometimes you don't want the y-axis reversed. In fact the example data that I've been using so far is best seen with the origin in the bottom-left.

Also, more generally, I can imagine that users don't expect the performance to depend on the reversed-ness of the axes :)

[almarklein]

plotly/plotly.js#5305

[almarklein]

Fixed in Plotly.js (plotly/plotly.js#5307). I think now we just need to wait for a new release of plotly.js and then a release of plotly.py.

[emmanuelle]

So cool! It should be this week I think, the timing is great.