vis-network icon indicating copy to clipboard operation
vis-network copied to clipboard

Poor performance/errant behavior on iOS 13

Open ptrckqnln opened this issue 5 years ago • 5 comments

I've confirmed that this bug can be reproduced with the examples at https://visjs.github.io/vis-network/examples/

I'm toying with a minimal implementation (4 nodes, 3 edges - one image node, shadows enabled, default config otherwise) and I've noticed that the performance when dragging nodes is significantly poorer on iOS (both Safari and Firefox, iPad Pro 11 and iPhone XS Max) than on any other platform I've tested. It performs beautifully on a cheap Android phone from several years ago, so hardware is certainly not the limiting factor.

Specifically, I notice that when I drag nodes around, the animation is quite choppy. The framerate does not appear to recover, as dragging the view around remains slow long after. Additionally, I notice node shadows flickering as I drag, and node/label text does not appear to become bolder when selected (unlike the edges) as it does on Android/macOS.

Update

I've just discovered that performance is fine on both the iPhone and iPad until I either:

  • tap anywhere on the canvas, or
  • zoom in close enough to fade labels

That is, dragging nodes around is as smooth as on any other platform until the moment I tap/zoom, at which point the animation suddenly becomes jarringly choppy (persisting even after I tap outside of the canvas/zoom out).

The other issues I described (flickering shadow, failure of node/edge labels to become bold) are always evident, however.

ptrckqnln avatar Oct 22 '19 03:10 ptrckqnln

Hi @ptrckqnln,

sadly I have no device I could use to test this. The only thing that may help right now are logs. Could you check if it logs some errors into the console, please?

Thomaash avatar Oct 22 '19 11:10 Thomaash

@Thomaash Unfortunately no errors are logged to the console. I'm trying to see what I can glean from the debugger with my iPhone on https://visjs.github.io/vis-network/examples/network/nodeStyles/circularImages.html, and immediately noticed a difference in the timeline (which at least confirms that I'm not simply losing my mind 😅).

Here's a profile of the application running as I drag a node around before tapping to select a node/zooming in: Screen Shot 2019-10-22 at 8 49 04 AM

And after tapping a node then dragging it around: Screen Shot 2019-10-22 at 8 49 32 AM

The green bars in the middle are composite/paint calls, and the purple bars are the js events (hammer events/timers). The green at the bottom shows CPU utilization (which is about 10% higher on average when the animation is choppy). Notably, in the first case, the paint call follows composite immediately (in the first image each one of those green bars is a composite + paint), whereas in the second case, there's an average delay of ~30ms between composite and then a doubled paint call, during which time it appears that JS execution is paused. This is a bit outside my expertise, so I'm grasping at straws at the moment, but I'll see what else I can dig up. Let me know if there's anything in particular you'd like me to test/retrieve.

ptrckqnln avatar Oct 22 '19 13:10 ptrckqnln

I've also learned that I don't need to tap on a node specifically to cause this issue, but rather anywhere on the canvas. There seems to be something about that tap that seriously disrupts rendering.

ptrckqnln avatar Oct 22 '19 13:10 ptrckqnln

I also see this on a m1 Mac book pro, Monterey 12.0.1, safari v15.1. Having the canvas selected causes the network to be very very slow. Unselecting the canvas speeds things back to normal. The same network works fine on chrome. I can't see any errors in the console. If I can help more please let me know.. my current work around is just to use chrome.

Thanks for the awesome package.

willfinnigan avatar Feb 04 '22 18:02 willfinnigan

Same here, MBP M1 Pro / Safari 15.3.

timosillander avatar Feb 16 '22 15:02 timosillander