Thanks Matt for a clear report about the problem.

We could send the data in batches, rather than all at once, but that's gonna add a lot of extra complexity to an already nontrivial communication between frontend and kernel.

I'd suggest we start with something easier, namely capping the total number of real numbers that will be returned to the frontend. We can do this by downsampling in space and/or time. This isn't crazy because the visualization has limited discernible spatial resolution, and we already know that the temporal resolution is too high because we're currently only showing every fifth time point! (A bad hack that I feel bad about, added by me during the manic demo prep.)

For example, we could set a maximum length for each of the x, y, and time dimensions, and then if the number of points returned by the simulator exceeds the number, we downsample uniformly in that direction before returning the data from the Julia process.

This would be a significant departure from the "generate simulation data and have CatColab visualize it," but would we bypass this problem if we generated the visualization .gif/.mp4 on the Julia-side?

Not crazy at all. Browsers have good support for playing videos now, right?

So the rumor goes! But I suppose this means we would have to make larger changes affecting what data we return and how we parse it?