Timeline Click / Touch delay

[aytech]

Hi, When dragging the timeline, the drag event doesn't fire immediately, but after the cursor travels some 5+ pixels. Also, if you click on the timeline axis and drag the cursor real slow, the drag event might not fire at all, even if you speed up the movement later (without releasing the left mouse button). I see that Hammer.js has demo on their front page where you can drag the square around, and it fires immediately, but on the timeline it feels sluggish Is there a way to configure the touch/click/drag events to fire immediately?

Thank you

[josdejong]

We haven't adjusted the hammer.js settings for this.

For touch devices you need such an offset to distinguish between a tap and a pan event. Looking at the website of hammer.js it looks like they do not have this offset on a desktop browser but only for mobile devices. Will be interesting to see how we can get a similar configuration.

You can access the hammer instance of a Timeline via myTimeline.hammer. Would be great if you could play around with this. Note that for vis.js v4 (unstable) we are moving to hammer.js v2, and vis.js v3.x uses hammer.js v1.x.

[aytech]

Tried playing with all available options on timeline.hammer, nothing works... Went through docs at https://github.com/hammerjs/hammer.js/wiki, tried their Tips&Tricks, no luck, can still reproduce the described effects... Thought of using fastclick (https://github.com/ftlabs/fastclick), but their docs say it doesn't have effect on desktop browsers. Even tried injecting hammer.js v2 into the current version of visjs, dragging still works, but the same issues persist, the drag action just wouldn't start immediately, but after some delay

[AlexDM0]

It could be that if you ONLY bind the drag, it does not have to check what sort of even it is. How would you differentiate a drag from a click if there's no dragging yet?

[aytech]

Hi Alex, what do you mean? I believe hammer does all the binding and we can only listen or trigger these events (and triggering is not recommended)

[josdejong]

@AlexDM0 but demo on the website of hammer.js demonstrates both dragging and clicking, so there seems to be a solution. I suppose you would have to check whether dealing with a mouse or touch event and act accordingly.

[AlexDM0]

Probably due to configuring the pan recogniser: https://github.com/hammerjs/hammer.js/blob/master/src/recognizers/pan.js#L21

[aytech]

I tried changing it to 1, but no effect

[aytech]

And its Hammer 2.0, 1.x doesn't have that

[AlexDM0]

I tried it with network in the v4 branch and that works fine. You'd have to rebuild hammer and rebuild vis for it to do something.

You can also do it in the 3.12 branch. Change line 29977 to 1 to fix it.

Here is the code snippet where the dragMinDistance is changed to 1:

      Hammer.gestures.Drag = {
          name: name,
          index: 50,
          handler: dragGesture,
          defaults: {
              /**
               * minimal movement that have to be made before the drag event gets triggered
               * @property dragMinDistance
               * @type {Number}
               * @default 10
               */
              dragMinDistance: 1,

That solves it.

I'm not sure if its configurable in hammer but it's hackable. In 2.0 it seems those are options, which would be why his example works better.

[aytech]

Ha, you nailed it :) Can it be added to the official repo? Changing this value during runtime doesn't have any effect

[josdejong]

Lets first check whether this doesn't have a negative effect on touch devices?

[AlexDM0]

Maybe we can do something with it in version 4.x where we switch to hammer 2.0. I never really thought it was a problem. You save a lot on the lack of redraws every single pixel you move the mouse.

Jos is playing with hammer 2.x at the moment so I'll leave the decision up to him :)

[josdejong]

@AlexDM0 I'm perfectly fine with fine tuning this (indeed in the v4 branch of vis.js), though in the end it must work ok on both desktop and mobile devices.

[AlexDM0]

As long as it will not stray from the hammer API. I don't really think hacking this in the way I did in my example is the way to go.

[aytech]

With this delay the timeline feels sluggish in desktop browsers. I see that Hammer has little demo on their home page that seems to lack that delay

[aytech]

Managed to modify the value of hammer configuration before instantiation, looks like an uber hack, but it works :) Thanks for the help!

[hansmaulwurf23]

The delay is also quite different in Firefox (38) and Chrome (43) (both Linux), even with a rather simple setup like the one from the demos: http://visjs.org/examples/timeline/other/groupsPerformance.html?count=1000

@josdejong is the hammerjs options going to be part of the timeline options? @aytech how did you change the hammer configuration?

Thanks Martin

[aytech]

Hi Martin, I just needed to get rid of the delay completely, so I changed the Hammer threshold to 0. Its set in vis.hammer.Pan.prototype.defaults.threshold

[aleosd]

@hansmaulwurf23, i've got same problem, did @aytech 's comment help you? I I have tried to change threshold value in my js file value before timeline creation, no difference.

[hansmaulwurf23]

@aleosd, yes it helped in my case, performance was better, cpu load a bit higher though. Did you forget to package the vis.js afterwards? Another problem might be, that the option is not really set on initialization. I think I set this directly somewhere in the source code of the timeline but reverted it again since updates will overwrite.

[aytech]

There's no need to modify the source code. After initialization vis object is part of the global window object. So you can update it directly after timeline initialization: // Create a Timeline var timeline = new vis.Timeline(container, items, options); window.vis.Hammer.Pan.prototype.defaults.threshold = 0;

Disclaimer: I did not check the latest version of the timeline app, maybe you can set it in options. My hack looks pretty ugly, although it works...

[josdejong]

Not tested but probably window.vis.Hammer.defaults.threshold = 0 works too.

[aytech]

Nope, doesn't work, at least in version 4.3.0

[josdejong]

also not if you set it before creating the Timeline?

[aytech]

Tried to update the threshold before and after, didn't make any difference...

[josdejong]

ok thanks for testing. at least the hack you proposed works :)

[caracal7]

Anybody solve delay problem in the last vis.js version?

[gabriellima]

Gentlemen, I'm experiencing delays in dragging Timeline with vis 4.6.1. The problem happens with newest Chrome 53.0.2785.116, but doesn't with Firefox.

I traced back the problem to element styles that are only generated with Chrome: touch-action and webkit-user-....

Look at the differences below:

Chrome <div class="vis-timeline vis-bottom" style="touch-action: pan-y; -webkit-user-select: none; -webkit-user-drag: none; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); height: 154px; cursor: auto;">

Firefox <div class="vis-timeline vis-bottom" style="-moz-user-select: none; height: 154px; cursor: auto;">

Would this be a browser or vis timeline issue?

[gabriellima]

Guys, Looking at Hammer website with Chrome, I found out that its homepage example has touch-action: none instead of touch-action: pan-y.

How may I use this option inside vis Timeline ?

[yotamberk]

@gabriellima Do you mean to add in a PR? Does it work for oyu when changing the CSS in the devtools?

[yotamberk]

Doesn't happen anymore in 4.18.0 with chrome 55.0.2883.87