Wait until canvas has finished updating?

[dsblank]

Is there a way the canvas can wait until the hold_canvas has finished updating? Actually, this may not be a hold_canvas issue, but I am using sync_image_data and that may be what I need to wait on.

For example, see this gif how the kernel continues to process data, and the canvas image changes:

How could I know when the updating is done?

(Relatedly, I only need to update the canvas image_data when the hold is done, if it is doing that more than once. Is there a way to see what messages are being processed? Like watching a log in real time?)

[martinRenou]

How could I know when the updating is done?

You can listen for image_data changes by observing it and call a callback when it changes.

def on_update(change):
    # This code will actually be called when the canvas `image_data` is updated

canvas.observe(on_update, 'image_data')

But if you set this up before starting your animation then on_update will be called multiple times during your animation, and it's actually impossible to know how many times (you cannot even count on this to record a movie of your animation, I tried and it's awful).

What I can suggest in your case is to do the following:

# Disable syncing of image_data before the animation
canvas.sync_image_data = False

# Perform your animation here
with hold_canvas(canvas):
    # ...

def on_update(change):
    # This code will actually be called when the canvas is updated
    #

canvas.observe(on_update, 'image_data')

# Ask for syncing the `image_data`, this will trigger the call of `on_update` automatically when the `image_data` is received
canvas.sync_image_data = True

I hope I was clear enough. This part is one of the most difficult in ipycanvas, because it's completely async.

[martinRenou]

1. Yeah, the front-end is designed to send the image_data only at the end of the hold_canvas. Sorry I see my code was not correct, I actually assumed you were making an animation as following:

for i in range(num_steps):
   with hold_canvas(canvas):
       # Drawings

If you do that then it makes sense to disable the sync before the loop

2. Setting sync_image_data = True (if it was previously False) should force this update.

I am thinking of introducing a new method download('file.png'), which would request the browser to download the current state of the Canvas. This approach would not be out-of-sync with other draw commands, but it has the drawback of not allowing you to retrieve the image in the Python process, instead the browser will prompt a FileSave window to the user, so the user can save the image on their machine. Would that kind of API be useful for you?
This would be another way to retrieve the Canvas image, I am not thinking yet about deprecating the image_data API.

[dsblank]

Thanks for the info!

1. Yeah, the docs could mention that image_data is not updated during the hold_canvas. That would clear up some confusion.
2. I couldn't get the wait to work correctly, I think because while Python was waiting, the update couldn't occur because the kernel was processing. I think I'd have to put something in a thread. So, I'll just let users know that they'll have to wait to take a picture of the canvas until it stops updating.
3. download("file.png") wouldn't be that useful for me. I can already get the image_data and do with it what I want. And users can right-click on the Canvas to download a png. What would help be would be a synchronous update_image_data(). But, like you say, that might be hard.

Anyway, I think I understand the limitations and can make-do on this issue for now.

[martinRenou]

And users can right-click on the Canvas to download a png

True! I should mention that in the documentation.

What would help be would be a synchronous update_image_data(). But, like you say, that might be hard

It's impossible to have it synchronous, but explicit requests to the image_data would be a good idea, a better idea than this sync_image_data attribute IMO.

Concerning wait, it's also a bit difficult to understand if you don't understand how the communication with the front-end works. I think it lacks documentation on that aspect. I should come up with some animations in the docs showing how the communication works, and what is happening with hold_canvas and wait.

[dsblank]

Another issue that I have encounter which I think I can attribute to the asynchronous update of the image_data: when running a few seconds of updates, the messages seem to get queued up, and the kernel is unable to respond to an interrupt. If I stick in a time.sleep(), then everything is ok. If there were an atomic image_data update, then I think this would run fine because there would be time to handle the interrupt as it would get into the message queue at the appropriate place.

[dsblank]

@martinRenou Is there a place I can insert a throttler? This page [1] has a nice discussion on debouncing and throttling... is there a place where I can put that in a subclassed Canvas?

[1] https://ipywidgets.readthedocs.io/en/latest/examples/Widget%20Events.html

[dsblank]

Well, I throttled my draw() method, and now it runs super fast, without overwhelming the kernel. In fact in runs so fast, I had to introduce a wait to slow it down some :) BTW, the throttle code given in the ipywidgets didn't work (I think due to issues running in Jupyter.) But code based on: https://gist.github.com/ChrisTM/5834503 did work. I think this solves all of my issues with ipycanvas!

[martinRenou]

Super nice. This throttling trick could be a good addition to the examples directory.

[dsblank]

I'll see if I can put together a simple example that shows off the power of the throttle. In my example, I can just forget about the issue and it will do the right thing (except for perhaps a final draw to make sure it is in sync). That is, I can call update as fast as the system will go, but it won't overload with useless updates. Here is my robot simulator running 100x real time: