Visdom: Zoom resets after updating plot

[dmitriy-serdyuk]

When I zoom in some particular region on a plot and a script calls updateTrace, the zoom resets and I have to zoom again. It is especially irritating when plotting a loss curve which updates frequently.

The plotly example doesn't have this problem.

[JackUrb]

Hi @dmitriy-serdyuk, I can see that this is probably pretty frustrating but I don't see a quick fix that has precedence over working out https://github.com/facebookresearch/visdom/issues/134, especially when that one is likely to change a lot of the server->frontend interactions.

This has a lot to do with how we're sending the update, namely that we currently "destroy" the old content by updating it with a new content_id on an update, forcing a component update on the frontend which redraws the whole plot. Possible temporary solutions range from broadcasting updates separately from how new plots are broadcast (thus requiring a separate handler to subscribe to updates) to creating new fields on the server-side that correspond to an update having happened, which then upon the frontend hitting componentShouldUpdate it can undergo different behavior that changes the state (and appends the new values to the existing plot) without redrawing the plot. I'd be happy to accept a PR that implements something along these lines in the meantime while I'm working on 134.

[rdevon]

This also applies to hiding plots from some experiments. For instance, I might have dozens of plots from several experiments that I'm doing a grid-search on, but I only want to monitor or show (to someone else) a few of them while the models are still training. But as soon as I adjust my view, everything resets, which is fairly frustrating when one is trying to do massive monitoring over many experiments sensibly.

I was surprised this still happens with update='append'

[JackUrb]

Hi @rdevon - I didn't realize that resizes were triggering this issue, but in the end it makes sense. All changes to the plot data or the viewpoint window lead to a re-render of the react component (hence why resizes and appends cause the issue), but the plotly context is destroyed in the process. This happens in the code here:
https://github.com/facebookresearch/visdom/blob/2ef12d43536360405c5a065e9f3eed282b8a76bf/js/PlotPane.js#L39

Given the changes since this issue was initially posted, a better implementation would either:
1) Find a way to replace the data and layout in the plot if it already exists (though I'm unsure if the chart would update to properly fill the new div size). This has the downside of being unable to retain zooms on plots that are given dimensions by the visdom.<> call as the new layout would probably override this.
2) On an update, if a plot already exists, copy any user applied opts on the frontend, render a new chart, and then apply the copied opts to the new chart. I don't know if there's an existing plotly API for being able to get applied frontend changes to the current chart.

I haven't had a chance to investigate or begin to implement either of the two approaches.

[rdevon]

Have the updates addressed this issue?

[JackUrb]

395 has remained a blocker for me on this project, and I haven't had the bandwidth to implement the fix using a method that wouldn't need it. Sorry for the long wait here, but I'm hoping to have something together by EOY.

[JackUrb]

Update @rdevon - I've actually found a fix to your particular issue (legend visibility) and I'll try to push out that change in the next few days (at least here, but not to PyPI until I've tested thoroughly)

[rdevon]

Nice!

[dmitriy-serdyuk]

It seems that now it breaks "reset axes" button =( I plot something, zoom in, append something to the plot, press "reset axes", nothing happens.

[dmitriy-serdyuk]

Although, autoscale button works. What is the difference between reset axes and autoscale? They seem to do the same stuff.

[JackUrb]

Autoscale removes all manual scaling, reset axes goes back to the previously assigned scale. Considering I need to copy over the previous scale and assign it, I suppose it makes sense that the normal reset axes would no longer work. I don't have a short term solution for this other than just using autoscale instead.