Plotly.js: image and heatmap traces jump/flash on Firefox and Safari
The new image trace seems to have a flashing/jumping behavior when zoomed in and panning on Firefox and Safari. (Firefox version 69.0, Safari version 13.0.3)
Example from https://plot.ly/python/imshow/
This jumping does not happen on Chrome but I do see it on Firefox/Safari. Not sure if it's related, but in all three browsers, the tooltip also seems to jump to another location when the pan is completed.
jonmmease
All 16 comments
@jonmmease I think the issue also occurs on heatmap (https://plot.ly/python/heatmap/). Could you rename the issue to reflect that?
The problem stems from reinjecting an image when pan operation is completed. I thought this pattern was safe since it's been used for a long time in heatmap. Maybe this issue only affects newer versions of Firefox :thinking: ?
antoinerg
on 21 Nov 2019
Could you rename the issue to reflect that?
Done, thanks!
jonmmease
on 21 Nov 2019
Hmm. I can't replicate in FF 70
etpinard
on 28 Nov 2019
Hmm, I am seeing it in FF 70 on Ubuntu. @antoinerg were you able to reproduce?
jonmmease
on 30 Nov 2019
Hmm, I am seeing it in FF 70 on Ubuntu. @antoinerg were you able to reproduce?
I can reproduce it in FF 70.0.1 (64-bit) on Linux (NixOS distro).
antoinerg
on 1 Dec 2019
I can also reproduce in Safari 13.0.3 on macOS 10.15.1.
On the same system, the problem does not appear in Chrome Version 78.0.3904.108.
firasm
on 10 Dec 2019
@antoinerg do you think there's an "easy" way to fix this bug?
Or do you think our canvas -> pixels -> img inside the _paper SVG is fundamentally flawed and FF does behaves as expected?
etpinard
on 7 Jan 2020
Or do you think our canvas -> pixels -> img inside the
_paperSVG is fundamentally flawed and FF does behaves as expected?
It's hard to say which one behaves right and I suspect the specification may not be clear in this regard.
do you think there's an "easy" way to fix this bug?
Idea for an easy fix: have two images (A and B) and alternate between the two. Once you pan, image B content is updated and moved in front of image A (so no flash in principle). Then if you pan again, image A content is updated and moved in front and so on. Hopefully, this approach works.
If we only target a fix for FF: leverage image-rendering: pixelated, draw the image only once and things will fly :racehorse:.
antoinerg
on 8 Jan 2020
So we're reverting the drag, then redrawing with the new view... and it seems like even if we do this synchronously, some browsers will do two repaints (if that's it, there will be async edge cases in other browsers too). I wonder if we can just not revert the drag, and tweak the redraw process if necessary so it still works right. I think it's this call that's doing it:
updateSubplots seems to modify some internal state as well as adjusting viewboxes, we still may need the internal state even if we don't change anything visible.
alexcjohnson
on 8 Jan 2020
This may be a problem with Firefox itself: Images are flashing when updates by img.src[]=url in Firefox >= 8.0
Potential solution: https://stackoverflow.com/questions/14704796/image-reload-causes-flicker-only-in-firefox/14711272#14711272
antoinerg
on 21 Jan 2020
FYI: using some navigator.userAgent-based solution here would be :ok_hand: with me.
It would be interesting to see how image-rendering: pixelated performs in comparison to the current algorithm. Using that in browsers that support it could be a big win and allow us to fix this problem in FF.
The solution in https://stackoverflow.com/questions/14704796/image-reload-causes-flicker-only-in-firefox/14711272#14711272 may be a quick and easy way to fix this bug in Safari (albeit with a potential performance cost).
etpinard
on 28 Jan 2020
The issue is twofold:
- Image is flashing (can be fixed by not redrawing the image)
- Tooltip appears at the position of the last click
EDIT: I opened an issue to tackle 2) since it affects other trace types (https://github.com/plotly/plotly.js/issues/4570)
antoinerg
on 6 Feb 2020
@etpinard at the moment, when an axis has a scaleanchor attribute (the default for image), the calc step is called on every pan operation. For the planned improvement to the image trace type, this is somewhat undesirable. We'd like to produce the image in calc once and then simply move/scale it in the plot phase when a pan operation is completed. The goal is to save ourselves from the sometimes expensive operation of looping over all the pixels in view (and then some). Do you see potential roadblocks or flaws in trying to achieve what I just described? How would you go about skipping the calc phase when it's being triggered by a pan?
antoinerg
on 18 Feb 2020
Here's the relevant logic that makes zoom interactions go through the 'calc' pipeline:
By the looks of it, all the range "constraints" operations are taken care of in
which is called during
from a few places in plot_api.js including in the "fast" 'axrange' edit pipeline:
So perhaps zoom/pan interaction _just work_ already under the fast 'axrange' edit pipeline? @antoinerg have you tried commenting the above block in _relayout to see in any tests fail?
We'll have to be extra careful though. I wouldn't want to trust 100% our test coverage for constraints.
But yeah, to answer your question, making zoom/pan on constrained axes not have to go through the 'calc' pipeline would be a huge win for image traces. Maybe 'axrange' works already, maybe we'll need a new flavour of that 'axrange' pipeline, but yeah we can do better than 'calc'!
etpinard
on 19 Feb 2020
(Ping, I updated my comment above)
etpinard
on 19 Feb 2020
This issue has been tagged with NEEDS SPON$OR
A community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort.
Sponsorship range: $10k-$15k
What Sponsorship includes:
- Completion of this feature to the Sponsor's satisfaction, in a manner coherent with the rest of the Plotly.js library and API
- Tests for this feature
- Long-term support (continued support of this feature in the latest version of Plotly.js)
- Documentation at plotly.com/javascript
- Possibility of integrating this feature with Plotly Graphing Libraries (Python, R, F#, Julia, MATLAB, etc)
- Possibility of integrating this feature with Dash
- Feature announcement on community.plotly.com with shout out to Sponsor (or can remain anonymous)
- Gratification of advancing the world's most downloaded, interactive scientific graphing libraries (>50M downloads across supported languages)
Please include the link to this issue when contacting us to discuss.
jackparmer
on 10 Sep 2020
Related issues
danielsamuels
·
3Comments
HunterMcGushion
·
3Comments
bryaan
·
3Comments
chriddyp
·
3Comments
boleslawmaliszewski
·
3Comments
Most helpful comment
So we're reverting the drag, then redrawing with the new view... and it seems like even if we do this synchronously, some browsers will do two repaints (if that's it, there will be async edge cases in other browsers too). I wonder if we can just not revert the drag, and tweak the redraw process if necessary so it still works right. I think it's this call that's doing it:
https://github.com/plotly/plotly.js/blob/4ab3b49c12e3e8be3800f7e4aacd4dddcf497357/src/plots/cartesian/dragbox.js#L770-L774
updateSubplotsseems to modify some internal state as well as adjusting viewboxes, we still may need the internal state even if we don't change anything visible.