Skip to content
This repository has been archived by the owner on Jul 29, 2019. It is now read-only.

MS IE and Edge slow when stabilizing is finished #3425

Closed
Head opened this issue Sep 7, 2017 · 9 comments
Closed

MS IE and Edge slow when stabilizing is finished #3425

Head opened this issue Sep 7, 2017 · 9 comments

Comments

@Head
Copy link

Head commented Sep 7, 2017

For example, open http://visjs.org/examples/network/exampleApplications/lesMiserables.html on Edge (latest version 40.15063.0.0).
Then move the whole graph: Utterly smooth.
Now wait a bit until all nodes are stabilized in their positions.
Move again and have a bad time.

@OACDesigns
Copy link

I'm also experiencing this on Edge 15.15063
It becomes virtually unusable as soon as stabalisation has completed.

@wimrijnders
Copy link
Contributor

wimrijnders commented Sep 7, 2017

So I've got a Window 10 machine running here now, to check this and other issues on Edge. It's a 1.4GHz Celeron, so not the fastest thing on the planet.

I ran the given example on Edge and in all honesty I have to say it's working quite well. I do notice, however, a difference with the usage of input devices:

  • The touch pad on my Logitech keyboard works smoothly as a baby's bottom. I can drag to my heart's content and all is responsive.
  • With the USB mouse, however, there is a significant lag while dragging, with the dragged node chasing the mouse cursor in discrete steps. As soon as I stop dragging, everything is smooth again.

Could this perhaps be a driver problem?

I'm wondering now what the symptons are that you are experiencing. Does it look like what I experienced with the USB mouse? Or is it something else more pronounced? What particular experience makes it virtually unusable and/or gives me a bad time?

I've also tried the worldCupPerformance example, with is a heavy-weight with about 1000 nodes and 10000 edges. Here, I do see significant difference with my i7. But I think that that can be forgiven with such a big network.


Stabilization, as the term is known within Network, is the step that is performed before anything is shown on screen, to assign decent starting positions for the nodes. I'm assuming you don't mean that, but that the nodes have stopped moving on screen.

@wimrijnders
Copy link
Contributor

@OACDesigns, how do I check the Edge version number? Have no clue and Bing isn't helping.

@Head
Copy link
Author

Head commented Sep 7, 2017

Yep, the moment the nodes have stopped moving it becomes laggy. Using a normal mouse and a high end gamer PC, latest "everything".

I made a video to demonstrate it (also showing where to find the version no): https://youtu.be/_xSYcFyVnGw

@wimrijnders
Copy link
Contributor

wimrijnders commented Sep 8, 2017

Thanks for the video, that helped.

What I'm seeing is that movement is smooth as long as the nodes are moving. When the movement stops, the full network drag is 'stuttering' (to give it a name). There are large pauses between movement and that movement is abrupt.

I also note:

  • zoom in/out is responsive
  • Drag of individual nodes is responsive
  • When separate nodes are moving again, the full network drag is also responsive

Does this sum it up? I realize I'm repeating stuff that you both have already mentioned.

And so my Edge version is: 20.10240.17113.0

@wimrijnders
Copy link
Contributor

wimrijnders commented Sep 8, 2017

So this looks like a refresh issue in the case that there is no movement of nodes, in combination with the full network drag. That's sort of a hint for where to look; I do wish though that I could reproduce this locally.

Any other symptons I should be aware of, besides the above?


Update: I think I got it; I spent half an age dragging around the network and I think I can feel the 'stuttering' now. It's not as pronounced as in the video, though.

Strange that a low-end machine performs better than a gaming computer. It must be a refresh timing issue of some kind.


Update 2: I also hereby note that the stuttering effect is completely absent on linux+(Chrome|Firefox). So I conclude that it's a difference in working between Edge and those browsers.

Suspects: the mouse drag event and requestAnimationFrame(). I'll also investigate how the refreshes are handled within the Network code, in particular if there's logic that determines to not update if the nodes aren't moving.

Would it be possible to test the issue on Firefox or Chrome on Win10? To narrow down the scope. I would appreciate that.

@Head
Copy link
Author

Head commented Sep 8, 2017

Chrome is totally fine! And oh my... Firefox is lagging too. That's not that good for our project :(

Chrome: Fine (60 FPS)
Firefox: Bad (2 FPS)
IE: Bad (1 FPS)
Edge: Worst (0.2 FPS)

Afaik no other symptons.

@wimrijnders
Copy link
Contributor

wimrijnders commented Sep 8, 2017

Right. I intend to make a special build for WIN, meant for testing by you, which disables the request frame animation altogether. By isolating that part, we can see if the problem is there. Will do it this weekend.

Update: Sorry, didn't get around to it yet, got stranded in yak-shaving bugs. It's still at the top of my TODO.

@wimrijnders
Copy link
Contributor

I'm happy to report that someone else, namely @justinharrell, has picked up the issue. You probably would have noticed that already with the notifications on this issue, but I'd like to use this opportunity to express my gratitude to named @justinharrell.

yotamberk pushed a commit that referenced this issue Sep 29, 2017
* Label performance improvements

* Label cleanup

* Fix drag performance in IE

* Fixed broken images still trying to draw

* Fixed merge and lint issues
primozs pushed a commit to primozs/vis that referenced this issue Jan 3, 2019
* Label performance improvements

* Label cleanup

* Fix drag performance in IE

* Fixed broken images still trying to draw

* Fixed merge and lint issues
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants