Failing to port a "realistic" filter design tool

[ma-laforge]

Using Julia 1.0.0 on Ubuntu 18.04...

Background

I ported over a simple, yet realistic (useful), graphical filter design tool that was working in Julia 0.6:

https://github.com/ma-laforge/InspectDR.jl/blob/master/notebook/2_interact.ipynb

You can see some snapshots of how the main "design" section looked in Julia 0.6 on my web page:
https://sites.google.com/site/malaforgeweb/design-assist

I am having trouble with the stability of the software - and I believe it is either due to Interact - or IJulia in general.

Every now and then, I can get both the inline plot & the Gtk plotting application (InspectDR) to show up properly and resond to the sliders, etc....

Problem

...but most often, Julia seems to hang - doing so silently, without eror messages (I don't even notice the "kernel died" message).
Usually, I don't even get a chance to touch the sliders. Things just hang when I try to display the widgets after the plot is shown.

I have sometimes seen the message "Invalid JSON in body of request." show up. I am not certain if that is relevant.

Question

I don't like opening an issue that is so vague, but

does anyone know why this might be happening - how I might fix this issue???

Comment

The sample notebook I have written might be a useful, realistic example for the Interact team to provide in the tutorials - in case it makes it a bit more desirable to solve a problem that is a bit less well defined.

[piever]

Not a real solution but a couple of comments:

• It's often more robust to run the app in a Blink window (see here), so maybe that could help as a stopgap solution
• There is a WIP PR (more like a massive rework of the frontend) to make the WebIO more robust: [WIP] Enormous rework of (mostly frontend) code. WebIO.jl#211, but I'm not sure what is the timescale for that or whether the branch is stable enough for you to try

As a separate issues, once this is sorted out, it be nice to start collecting all these apps package authors are doing using Interact in some "ecosystem" tab in the docs.

[ma-laforge]

I have been meaning to try out Blink for a few months now (I have always found the IJulia framework to be slow and unpredictable)....

...But I get the following error with Julia v1.0 on 18.04:

[...]
WARNING: could not import Base.quit into AtomShell
ERROR: LoadError: IOError: connect: connection refused (ECONNREFUSED)
Stacktrace:
 [1] try_yieldto(::typeof(Base.ensure_rescheduled), ::Base.RefValue{Task}) at ./event.jl:196
 [2] wait() at ./event.jl:255
[...]

Comments

• I basically get the same thing with Julia v0.7 as well.
• Note the warning for Base.quit - in case that is not typical.
• I have installed atom shell with Blink.AtomShell.install(). Not certain if it worked, though.

[piever]

Concerning Blink, I wonder whether you're hitting JuliaGizmos/Blink.jl#128 and the fix in JuliaGizmos/Blink.jl#128 (comment) would fix it for you.

For the notebook, I've been testing it locally and if I run jupyter from terminal I start getting:

[I 11:44:33.610 NotebookApp] Malformed HTTP message from 127.0.0.1: Content-Length too long
[I 11:44:33.617 NotebookApp] Malformed HTTP message from 127.0.0.1: Malformed HTTP request line

Maybe some issues with the exchange of information between the notebook and InspectDR? I'm really not sure. Could be useful to compare with Blink.

Also, there seems to be some strong flickering with the plot, I'm not sure where that comes from and if it can be fixed on the InspectDR side.

[ma-laforge]

Thanks for the links. I guess I should have checked the issues with Blink first.

The HTTP messages are interesting. I do not see those; maybe I should figure out how to run Jupyter from the terminal (it might end up being faster as well?). I might also need to learn how to use those programs that read socket traffic.

Flickering plot:
Yes. I noticed it to... but for me it looked like the entire Jupyter "frame" was blinking (plot + sliders). Even worse: I often noticed that the entire web page jumped when I moved the sliders.

I must admit I cannot see the flickering when I remove the plot from the list of displayed objects (only the widgets are displayed)... On the other hand, I believe there was still flickering when I plotted from the external Gtk application (not sending an image back to Jupyter).

I wonder if it could have something to do with messages being stalled while the plot is being rendered (a relatively slow process)...

I guess I have a few things to figure out. Thanks.

[ma-laforge]

Blink Tests

I just pushed a version of 2_interact.jl specialized for Blink:
https://github.com/ma-laforge/InspectDR.jl/tree/master/Blink
(Sorry, only on master branch at the moment)

Wow! Thanks for pointing me to Blink. My filter design tool is both very robust and fast with Blink.

...I wonder why IJulia notebooks are so flaky on my system. Is it just me? No one else seems to complain about the speed/robustness of IJulia notebooks (that I have noticed).

Other interesting observation

The updates are extremely responsive when I only use the Gtk application for plotting (deactivate inline plotting).

That means that there is still a fair amount of overhead in sending the .png plot image back to Blink (because the exact same routines are used to draw to a PNG canvas that are used to draw to a Gtk widget) ... Unless Cairo is significantly less efficient at drawing on a PNG canvas than a Gtk widget.

[piever]

...I wonder why IJulia notebooks are so flaky on my system. Is it just me? No one else seems to complain about the speed/robustness of IJulia notebooks (that I have noticed).

I don't complain simply because I don't use them :) I think Blink is simply much better to deploy an app locally.

Concerning the extra overhead in sending the png plot, I observed something similar trying to use Makie in an Interact setting.

Some of it may be due to the fact that the plot is redrawn for every intermediate value of your slider (as the observable updates every time you move the slider, even without releasing). To mitigate this you can throttle the observable. I.e., if you are using slider(1:100, value = obs) you can update the plot on obs_throttled = throttle(.05, obs). In this way it tries to redraw at most once every 0.05 seconds and avoids queuing up jobs.

Concerning delays due to drawing the png in Blink, I'm taking the liberty to ping @SimonDanisch as I think he has done some thinking on it to integrate Makie and WebIO.

[SimonDanisch]

Drawing an image that got generated in Julia in a web browser will always be kind of slow compared to a setting where you share the memory space ;)
But it definitely doesn't help, that in the current setup it will end up as a base64 encoded string that needs to be send over a websocket, possibly encoded as a json on top of things...There are several bottlenecks on that route, and surprisingly, ImageMagick writing the png to a stream takes a significant amount of time. If I remember correctly it was more than 50% of the total time ;)

[ma-laforge]

@SimonDanisch: a web browser will always be kind of slow compared to a setting where you share the memory space ;)

Good point. It is also interesting to note that refresh operations have much more lag from IJulia notebooks than from Blink. That means, in theory, it should be possible to speed up IJulia's rendering.

Though I think that I am hitting is something even more problematic in IJulia (before the PNG speed issue) if I get "Malformed HTTP message" messages from IJulia.

Maybe the solution is to just throttle things for now as @piever suggests. I had considered it, but never actually implemented that solution. I did not know about the throttle() command: That's perfect. I should have to problem throttling with this.