-
Notifications
You must be signed in to change notification settings - Fork 9
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
Matplotlib backend in a web worker #6
Comments
This is indeed possible. I have a plan involving comlink. If anyone is interested in implementing this, I can explain what I'm thinking. |
I think we should also open an upstream issue at matplotlib, see if there is any interest there and try to get them involved. @madhur-tandon Might also have some perspective on this. |
I think the point here is to use the existing implementation as-is but after wrapping dom calls in Comlink proxy. Though it occurs to me that we should just wrap the entire DOM with Comlink and then code on a webworker can transparently use all of the DOM calls, with the caveat that they all become async. |
Once we implement pyodide/pyodide#1503, we can remove the async caveat. |
Right, but we have our own matplotlib backend and before doing much more development work on it, I think it would be good to discuss what's the future of it. Are we going to have to maintain it forever or if there is a possibility to upstream at least part of it. It's indeed a bit orthogonal to the above technical discussion, but it would still be good to have a long term plan for this matplotlib backend. At least it would be good if someone from matplotlib was vaguely following these discussions. |
So I think the point here is this though: matplotlib has an API that consumes user input events and produces an image. The DOM is an API that produces user input events and consumes images. All that really needs to be done in the matplotlib backend is wiring it together. It sorta seems to me like this is most naturally our responsibility in Pyodide. |
Hi, not sure if this helps but long ago I implemented an HTML5 Anyway, let me know if this is of use here and I can revive it back for the current Pyodide. |
I think you are better equipped to judge than we are, I personally don't know anything about matplotlib. I'd be interested to discuss further after the release. |
Thanks for the input @madhur-tandon ! I also saw somewhere a mention of HTML5 backend being one of the possible topics for matplotlib GSoC this year (unless I'm mixing up something). So I think after the release we could reach out to matplotlib devs what would be the best way to move forward with these 2 backends that we have and their planned roadmap. Clearly communication with the webworker in Pyodide would still be on us though :) |
Yeah it would be great if we could upstream an exact match on the HTML5 API. |
@madhur-tandon If you could sync it with |
@rth For the matplotlib GSoC project this year, I was one of the mentors :) The one which I made uses I shall try to sync it with |
I think the proper interface for this is roughly as follows: we should make a
The argument You would have to call This logic would then not have to care about workers at all, it would be the responsibility of the front end implementer. @madhur-tandon Does this sound reasonable? |
Nice, thanks all for the comments and ideas for future implementations 👍 For now if someone is reading this thread and would like a basic workaround, the following code snippet patching import base64
import os
from io import BytesIO
os.environ['MPLBACKEND'] = 'AGG'
import matplotlib.pyplot
def ensure_matplotlib_patch():
_old_show = matplotlib.pyplot.show
def show():
buf = BytesIO()
matplotlib.pyplot.savefig(buf, format='png')
buf.seek(0)
# encode to a base64 str
img = base64.b64encode(buf.read()).decode('utf-8')
matplotlib.pyplot.clf()
matplotlib.pyplot.show = show Again this is very basic but might do the job in some cases. The base64 encoded image can then be used as needed. |
I should be able to revive this over the weekend. Sorry for being late but India is in a pretty bad state due to the pandemic right now. |
No need to apologize! Thanks for volunteering.
Best wishes to you and your family. |
An update, I am almost done with reviving the html5 The switch seems to have happened somewhere in this commit: matplotlib/matplotlib@370e9a2#diff-0a415dbb618fcfb73e6191c735f6e5a91f530d4a29b8886afdfd56604892de61 |
I have the renderer ready in my |
I think if you would just open a pull request that would be easiest. |
Okay, I am gonna open it from my fork's |
What is the status on this? The "from js import document" call is still there. Does the API for set_frontend exist already? |
I couldn't get @jtpio 's example to work, but here's a workaround that's working for me:
It basically just tricks the matplotlib backend into thinking everything is fine. I've only tested it with the default backend |
For reference JupyterLite removed this workaround in jupyterlite/jupyterlite#911. So not sure it still applies to newer version of Pyodide. |
At the moment using
matplotlib
when Pyodide is loaded in a web worker with the following code snippet:Gives the following error as it tries to create new elements with the wasm backend:
There is already a "Caveats" section in the docs mentioning limitations when using Pyodide in a web worker: https://pyodide.org/en/latest/usage/webworker.html#caveats
Maybe there could be another backend for matplotlib that would work in a web worker. Or document a workaround (if that's possible).
The text was updated successfully, but these errors were encountered: