As we start adding onto the initialization routine, we should move away from placing Pyodide on the main thread and onto a separate worker thread. This will give less of a "freeze" feeling while still allowing us to maintain a single shared environment. Plus, this allows us to move away from the matplotlib-pyodide's backends in favor just an IO stream re-capture.
The most promising approach is to use a Blob web worker similar to what is proposed on SO by vsync:
<!DOCTYPE html>
<script id="worker1" type="javascript/worker">
// This script won't be parsed by JS engines because its type is javascript/worker.
self.onmessage = function(e) {
self.postMessage('msg from worker');
};
// Rest of your worker code goes here.
</script>
<script>
var blob = new Blob([
document.querySelector('#worker1').textContent
], { type: "text/javascript" })
// Note: window.webkitURL.createObjectURL() in Chrome 10+.
var worker = new Worker(window.URL.createObjectURL(blob));
worker.onmessage = function(e) {
console.log("Received: " + e.data);
}
worker.postMessage("hello"); // Start the worker.
</script>By the looks of it, the use of a blob will be supported on modern browsers (~ < 5 years)
https://caniuse.com/bloburls
As we start adding onto the initialization routine, we should move away from placing Pyodide on the main thread and onto a separate worker thread. This will give less of a "freeze" feeling while still allowing us to maintain a single shared environment. Plus, this allows us to move away from the
matplotlib-pyodide's backends in favor just an IO stream re-capture.The most promising approach is to use a Blob web worker similar to what is proposed on SO by vsync:
By the looks of it, the use of a
blobwill be supported on modern browsers (~ < 5 years)https://caniuse.com/bloburls