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

Timeline: Chrome (Mac/Debian): Stuttering touch/drag of timeline produced by mousewheel usage in another viewsc #2023

Closed
kuehn-sba opened this issue Aug 17, 2016 · 20 comments

Comments

@kuehn-sba
Copy link

kuehn-sba commented Aug 17, 2016

When playing around in Chrome of my Mac with the embedded timeline within our web system, I've noticed that the timeline begins heavily to stutter when previously the mouse wheel was used in any scrollable content.

The problem remains even exist when the URL is reloaded again. The only way to get a "smooth scrolling" of timeline back, is to close Chrome browser or to open a new tab.

You can reproduce it, when:

  1. Open: http://visjs.org/examples/timeline/other/performance.html
  2. draw 10000
  3. Zoom out timeline to the max and touch and drag the timeline a lot to the left (it will scroll smooth all the time)
  4. Now resize the browser window to a small size, so that a vertical scrollbar appears
  5. Drag the scrollbar to the bottom without using the mouse wheel !!! (only by dragging the scrollbar)
  6. Resize the browser window to big size and touch and drag timeline a lot to the left -> (new items will appear and the scrolling of timeline is smooth all the time - no problem at all)
  7. Now Resize browser window to a very small window, so that a vertical scrollbar appears again
  8. And now use only the mouse wheel to scroll the scrollbar to the bottom
  9. Resize the browser window to a big size and touch and drag the timeline a lot to left (now the timeline will start heavily to stutter!!)
  10. Reload URL -> zoom out to max-> scroll timeline to left -> it will start to stutter again after touch and drag the timeline

The problem was found when using Chrome on Unix (as ubuntu) and Mac.
That problem has nothing to do with resizing browser view, because stuttering appears in general, when using a mouse wheel for scrolling a scrollable element (e.g. combobox...) before.

I hope you can reproduce and identify the problem.

Maybe it has something to do with Hammer.JS, what you use internal for touching.
I can see inside your source that you use Hammer.JS - v2.0.6 - 2015-12-23.
For testing purpose i had changed to hammer.js 2.0.8 code(replaced lines 11206-13776), but nothing helps (still stuttering).

@kuehn-sba kuehn-sba changed the title Timeline: Chrome (Max/Linux): Stuttering scrolling of timeline produced by mousewheel usage in another views Timeline: Chrome (Max/Linux): Stuttering touch/drag of timeline produced by mousewheel usage in another views Aug 17, 2016
@kuehn-sba
Copy link
Author

kuehn-sba commented Aug 17, 2016

my tests so far in vis.js:

line 16847 Range.prototype._onDrag emits rangechange event:

line 17819

   this.on('rangechange', function () {
      if (this.initialDrawDone === true) {

// debug outputs are without stuttering

        this._redraw();
      }
    }.bind(this));

line 18348

Core.prototype._redraw = function () {

 // debug outputs are stuttering in that case of using mousewheel in any other context/content before
...
}

if I analyze the loop of redrawing all components in line 18495, i noticed that stuttering will be produced by repainting Labels when redrawing timeAxis. So If I left out line 23783:

//this._repaintLabels();

stuttering is gone, but not timeaxis labels will be paint. Problem should be inside that function.

@kuehn-sba
Copy link
Author

kuehn-sba commented Aug 18, 2016

I was exiting the function at several lines and I could noticed:

23861 step.next();  return; 
// will allow smooth scrolling

and

23861 step.next(); 
23862 next = step.getCurrent(); return; 
// will produce stutter

.... produced by moment obj in the while loop?

@kuehn-sba
Copy link
Author

kuehn-sba commented Aug 19, 2016

Please, can anyone test/confirm that stutter problem? The timeline can hardly be operated by the stuttering...

@kuehn-sba kuehn-sba changed the title Timeline: Chrome (Max/Linux): Stuttering touch/drag of timeline produced by mousewheel usage in another views Timeline: Chrome (Max/Debian): Stuttering touch/drag of timeline produced by mousewheel usage in another views Aug 19, 2016
@kuehn-sba kuehn-sba changed the title Timeline: Chrome (Max/Debian): Stuttering touch/drag of timeline produced by mousewheel usage in another views Timeline: Chrome (Max/Debian): Stuttering touch/drag of timeline produced by mousewheel usage in another viewsc Aug 19, 2016
@kuehn-sba kuehn-sba changed the title Timeline: Chrome (Max/Debian): Stuttering touch/drag of timeline produced by mousewheel usage in another viewsc Timeline: Chrome (Mac/Debian): Stuttering touch/drag of timeline produced by mousewheel usage in another viewsc Aug 19, 2016
@JesperJohnsson
Copy link

We're currently having the same issue on windows/mac/linux & chrome where when the user scrolls anywhere in the application the timeline starts to stutter. Opening a new tab/window seems to solve the issue until the user scrolls again. But a more permanent solution would be nice :)

@kuehn-sba
Copy link
Author

kuehn-sba commented Aug 22, 2016

In my case...no problem with win7 chrome. It occurs only when using mousewheel before. Yes, opening a new tab will solve it. Maybe the memory that was used will be flushed for that case

@JesperJohnsson
Copy link

JesperJohnsson commented Aug 22, 2016

Yeah we're having exactly the same problem with the mousewheel and it's exactly as you described the problem in your first post.

@mojoaxel
Copy link
Member

@JesperJohnsson Thanks for confirming this issue!! Is there a simple way to reproduce this? The (many) steps in the description are a little hard to follow.
I still don't know what you guys mean with "stutter". Is it a rendering issue or is it a problem with the interaction?

@kuehn-sba
Copy link
Author

kuehn-sba commented Aug 22, 2016

it will freeze the gui with or without redrawing new items. How i had said, dragging the timeline to left or right starts stuttering. The hammer events for touch and drag are proceeded well without any blocking, but the redrawing process stutters. But why will it be a result of scrolling any content by a mouse wheel (before, everything works fine)

@JesperJohnsson
Copy link

The issue doesn't seem to be happening on either safari or edge, it seems to be a problem with chrome. @mojoaxel the easiest way to reproduce the problem is to follow @kuehn-sba instructions :)

@JesperJohnsson
Copy link

What's the status of this issue, is it something you are trying to fix @mojoaxel, or is it further down on your priority list? :P

@mojoaxel
Copy link
Member

@JesperJohnsson I'm not the lead-developer or something...I'm just a guy like you that is helping out, trying to keep this project from collapsing under a mountain of issues 😉

I'll be happy to review and merge a pull request but I don't think that I'll find the time to fix this issue myself in the near future.

the easiest way to reproduce the problem is to follow @kuehn-sba instructions :)

To be honest: I still have problems reproducing this. I think we need a really simple example (max. steps) to reproduce this so that people can debug it.

Maybe you also can try to reproduce it on other browsers/platforms. Could be a browser issue.

@kuehn-sba
Copy link
Author

kuehn-sba commented Aug 31, 2016

To be honest: I still have problems reproducing this. I think we need a really simple example (max. steps) to reproduce this so that people can debug it.

The above example shows when and when not the issue will produced.
If you only want test the bug then try only these steps:

  1. Take a OSX or Debian with Chrome
  2. Open: http://visjs.org/examples/timeline/other/performance.html
  3. draw 10000
  4. zoom timeline to max out, so that a lot of data will be displayed.
  5. resize the browser window to a very small width, so that a vertical scrollbar appears
  6. use the mouse wheel to scroll the window to the bottom (don't focus the timeline)
  7. resize the browser window to a big height, but less width so that the timeline will display a lot items above the others and move the timeline a lot left/right
  8. stuttering should start instantly

@mojoaxel
Copy link
Member

Ok, I created an example on jsbin with a lot of content to scroll. With this it should be easy to reproduce this issue without the window resizing:

  1. Go to http://jsbin.com/pojano/2/edit?js,output
  2. Use mouse wheel to scroll the output down an up again
  3. Try to move the timeline left/right

I still don't see stutters after vertical scrolling 😣 What am I doing wrong?

@mojoaxel
Copy link
Member

AHH! Now I see what you meen. I think I can reproduce it now:

  1. Go to http://jsbin.com/pojano/2/edit?js,output
  2. Open the HTML Panel at the top.
  3. Close the HTML Panel at the top.
  4. Try to move the timeline left/right

Looks like an browser (Chrome) issue to me. This will be hard to figure out.

@JesperJohnsson
Copy link

Yeah I think it's a chrome specific issue, tried my application on safari, chrome, edge and it's only chrome that I get the problem.

@mojoaxel
Copy link
Member

Ok. I think we can close it here.
Feel free to report it to the Chrome dev team.

@mojoaxel
Copy link
Member

mojoaxel commented Sep 1, 2016

@kuehn-sba Feel free to reopen the issue if you still think this is a vis.js problem! Because the issue seems to only appear on Chrome I think we reasonably can assume that it is a browser issue.

In any case, there are no commercial support for this project at the moment (see #1781), so there is almost no chance that somebody will take the time to debug this edge case in depth!

@kuehn-sba
Copy link
Author

kuehn-sba commented Sep 13, 2016

I have report that bug to the chrome dev team:
https://bugs.chromium.org/p/chromium/issues/detail?id=646294

@JesperJohnsson
Copy link

Chrome on Windows is where I get the problem so, it doesn't work there as you stated @kuehn-sba

@kuehn-sba
Copy link
Author

kuehn-sba commented Nov 4, 2016

I have to take an eye on this further, but it seems chrome version 54.0.2840.87 Final (for mac 02.11.2016) fixed that issue (no stuttering so far).

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

3 participants