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

Widgets: skip intermediate callbacks during throttling #5127

Closed
rossant opened this issue Feb 14, 2014 · 7 comments · Fixed by #5170
Closed

Widgets: skip intermediate callbacks during throttling #5127

rossant opened this issue Feb 14, 2014 · 7 comments · Fixed by #5170
Milestone

Comments

@rossant
Copy link
Contributor

rossant commented Feb 14, 2014

Suppose you have a slider, with a callback function (interact) that takes 2 seconds to display a plot (intensive calculations). If you move the slider for a few seconds, many on_change callbacks will be called successively. The throttle queue becomes longer and longer, the widget goes through many changes, and you have to wait dozens of seconds before the widget stops updating.

In this case, shouldn't the intermediate steps be killed before they are processed, so that only the most recent callbacks in the queue stay alive?

@dawehner
Copy link
Contributor

Maybe it would be possible to use something like an mouse-up event instead.

@jasongrout
Copy link
Member

I thought the design was that after 3 queued up messages or so, changes would be merged into a final queued message. It shouldn't be queuing up every change.

@rossant
Copy link
Contributor Author

rossant commented Feb 14, 2014

I thought the design was that after 3 queued up messages or so, changes would be merged into a final queued message. It shouldn't be queuing up every change.

You're right, it does seem that only three updates occur after the end of the interaction (i.e. when I stop moving the slider). Here is the test script I used:

import time
from IPython.html import widgets
@widgets.interact(x=(0, 255))
def f(x):
    time.sleep(3)
    print(x)

However, when the function takes a few seconds (or more) to complete, it does seem a bit weird to see three updates during the 10 seconds that follow the end of the interaction. Maybe this arbitrary number 3 should depend on the execution duration of the function? Or could there be a single update after the end of the interaction?

@jdfreder
Copy link
Member

I thought the design was that after 3 queued up messages or so, changes would be merged into a final queued message. It shouldn't be queuing up every change.

@jasongrout is right, this is how it was designed to work,

There is a property of the JS widget model that allows you to change this, this.msg_throttle = 3;.

@jasongrout
Copy link
Member

Perhaps this throttle number should be exposed on the python side.

@minrk
Copy link
Member

minrk commented Feb 14, 2014

Perhaps this throttle number should be exposed on the python side.

I was just about to say the same thing. @jdfreder is there any reason not to add msg_throttle = Int(3, sync=True) on the Python side?

@jdfreder
Copy link
Member

I was just about to say the same thing. @jdfreder is there any reason not to add msg_throttle = Int(3, sync=True) on the Python side?

Nope, just added it in #5170

@minrk minrk added this to the 2.0 milestone Mar 26, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants