Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panes with large data sizes may load in after swapping away from the env they're fetched for. #80

Open
ghost opened this issue May 10, 2017 · 3 comments
Labels
bug Fix Proposed There is a proposed fix for this issue that just needs to be acted on. help wanted For issues that welcome community support

Comments

@ghost
Copy link

ghost commented May 10, 2017

I have an visdom environment with large images in environment '0' and I'm accessing the server remotely. When I load the environment '0', the first image takes a long time to load and loads in '0'. If I then change to environment '1' on the webpage, the rest of the images load in the environment '1', even though they were assigned to '0'. No big deal, just wanted to file a report for it.

@ajabri
Copy link
Contributor

ajabri commented May 11, 2017

Hi @cpdurham !

Yes you're right. I've observed this myself as well. I think the socket should be flushed when the env is changed. Another option is to just refresh the page. I'll get to this sometime soon -- unless you want to give it a try? ;)

@JackUrb JackUrb added the bug label Dec 13, 2017
@JackUrb JackUrb changed the title Remote image loading issue Panes with large data sizes may load in after swapping away from the env they're fetched for. Jan 12, 2019
@JackUrb JackUrb added the help wanted For issues that welcome community support label Jan 12, 2019
@JackUrb
Copy link
Contributor

JackUrb commented Jan 12, 2019

To anyone who wants to try to fix this, a really simple method is to just ignore an incoming window when it arrives at the socket if it doesn't belong to the current env.

https://github.com/facebookresearch/visdom/blob/530e786b9a8005bfbac24092cd52ea6d0f4e3a81/js/main.js#L262

@JackUrb JackUrb added the Fix Proposed There is a proposed fix for this issue that just needs to be acted on. label Sep 13, 2019
@Aryanamish
Copy link

I am trying to solve this bug but I don't think you can do it in the main.js because the server is not sending the envID with the window object so will have to change the backend as well, to fix this issue

Data sent from he backend through websocket
{"command":"window","id":"window_3b5444d7cdd4a4","title":"","inflate":true,"width":null,"height":null,"contentID":"ffc60a8d-a167-4565-bac3-104fdeef1909","content":"This is enviroment 0","type":"text","i":0}

Aryanamish added a commit to Aryanamish/visdom that referenced this issue Dec 2, 2022
Updated the backend to send envID with the render information.

Updated the Front End to ignore the incoming window when it is not in the current selected environment
Aryanamish added a commit to Aryanamish/visdom that referenced this issue Dec 6, 2022
Updated the backend to send envID with the render information.

Updated the Front End to ignore the incoming window when it is not in the current selected environment
JackUrb added a commit to Aryanamish/visdom that referenced this issue Dec 6, 2022
@hpdang hpdang removed the codeheat label Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fix Proposed There is a proposed fix for this issue that just needs to be acted on. help wanted For issues that welcome community support
Projects
None yet
Development

No branches or pull requests

4 participants