Use CSS to support fast image rendering on linear axes

[almarklein]

Closes #5305

• A mock based on existing image_axis_reverse is added. I converted the image to base64-encoded PNG. I also swapped the red and green channel to avoid confusion between the two similar mock cases.
• Styling is applied to flip the image as needed.
• A test is added to ensure that the hover tooltip displays the correct info.

Trying this out:
Test script to test with local (dev) plotly: https://gist.github.com/almarklein/db9e1a2faec6890d1156e6ec546d7ecc
Via codepen (uses latest Plotly from CDN): https://codepen.io/almarklein/pen/XWjbJyQ

@emmanuelle @antoinerg
cc: @plotly/plotly_js

[almarklein]

Actually, it looks like the tooltip displays the correct image values already. I don't know how the picking is implemented, so I have no idea if this makes sense.

[antoinerg]

Actually, it looks like the tooltip displays the correct image values already. I don't know how the picking is implemented, so I have no idea if this makes sense.

It looks good to me too. The hover routine is more robust than I thought: it does get the right pixel information regardless 😸

[antoinerg]

Nice work @almarklein!

You can now 🔪 these lines since they don't apply anymore 🎉

plotly.js/test/jasmine/tests/image_test.js

Lines 427 to 428 in cdd836c

	['xaxis.range', [50, 0]],
	['yaxis.range', [0, 50]]

[almarklein]

The image comparison tests also fails: not ok 162 image_opacity should be pixel perfect. Any idea why this mock would somehow be affected?

Could you please keep (expand) the old test with autorange and add new tests with defined ranges?

Will do.

[archmoj]

The image comparison tests also fails: not ok 162 image_opacity should be pixel perfect. Any idea why this mock would somehow be affected?

The transparency is applied by style in that case.
Please pick or apply these changes so that image_opacity renders with transparency.

[archmoj]

The image comparison tests also fails: not ok 162 image_opacity should be pixel perfect. Any idea why this mock would somehow be affected?

The transparency is applied by style in that case.
Please pick or apply these changes so that image_opacity renders with transparency.

Here is the commit: c417e22

[almarklein]

Thanks! I added your commit to the PR.

It appears this block could be simplified to:

Wow, it does ... I'm pretty sure this is one of the things I've tried. Anyway, less code is better!

It looks like the tests for the image_opacity are fixed. But now: not ok 111 gl2d_subplots_anchor should be pixel perfect.

edit: nevermind, it looks like the image tests pass now.

[archmoj]

@almarklein
I could simply add a commit on a dev branch to address all my above comments and generate the new baseline.
What do you think?

[archmoj]

@almarklein
I could simply add a commit on a dev branch to address all my above comments and generate the new baseline.
What do you think?

Could you please pick 8a9380e and update PR description?

[almarklein]

It looks like I was misunderstanding the way _hover() worked. Frankly, I'm still a little confused. They are neither "scene coordinates" nor screen coordinates. We are not cheating the test here, are we? ;)

[archmoj]

No. That's why I added x and y to the hovertemplate test.

[almarklein]

Yes, that bit is reassuring :)

[almarklein]

Thanks for the help @archmoj !

[archmoj]

Thanks for the help @archmoj !

My pleasure. You solved the tricky part 🥇

LGTM.
@antoinerg would you please review this PR?

[antoinerg]

Beautiful work @almarklein and thank you for addressing all the comments! I think the code got much cleaner

💃 💃 💃