It appears far too easy to break the Websocket connection in VSCode, any of the following will cause a plot to be killed and unable to be resurrected:
Dragging the plots pane from one window location to another.
Clicking the left/right arrows in the plots pane.
Putting the computer to sleep.
@SimonDanisch and I talked about this, and we feel one potential improvement here is to not immediately clean up all resources related to that websocket (e.g. don't close the Session object) but rather use a LRU cache or async timeout or somesuch to keep some number of the plots alive on the backend, in the even that VSCode attempts to reconnect. Even better would be if this behavior is configurable, for instance in some cases it may make sense to keep plots for 5 minutes, in others it may make sense to keep them for 5 hours.
As a bonus usability improvement, it would be nice to have fallback HTML that appears in the plots pane when the websocket connection is refused, saying something like "plot was garbage collected, please re-plot in VSCode".
staticfloat
commented
11 months ago
It appears far too easy to break the Websocket connection in VSCode, any of the following will cause a plot to be killed and unable to be resurrected:
@SimonDanisch and I talked about this, and we feel one potential improvement here is to not immediately clean up all resources related to that websocket (e.g. don't close the
Sessionobject) but rather use a LRU cache or async timeout or somesuch to keep some number of the plots alive on the backend, in the even that VSCode attempts to reconnect. Even better would be if this behavior is configurable, for instance in some cases it may make sense to keep plots for 5 minutes, in others it may make sense to keep them for 5 hours.As a bonus usability improvement, it would be nice to have fallback HTML that appears in the plots pane when the websocket connection is refused, saying something like "plot was garbage collected, please re-plot in VSCode".