Ah, yes. I forgot that my issues with trying to do rendering in the
browser shared some similarities here.
When I did the last major backend refactoring (which is coming on 6
years ago now), I considered exactly this, which is why draw_path takes
both a path object (which is unlikely to change) and a transform. It
turned out to not be terribly useful for most the backends we have,
since PDF, PS, SVG (at least in the versions of the specs we’re using)
all scale the stroke width along with the vertices, so you couldn’t, for
example, zoom in on a line plot without the line width exploding. The
Agg backend is able to perform the transform itself since we wrote it to
not scale the stroke using the path’s transform, but there’s little
advantage since it’s all software anyway. But the API still works this
way even if nothing takes advantage of it. Though technically paths are
mutable, since they store Numpy arrays which are mutable, in practice
they are rarely if never mutated (I’ll have to verify this, but
certainly in the course of panning and zooming, they wouldn’t be), so it
should be possible to know whether a path is already on the GPU by
checking its id against a table of what’s on the GPU.
The other wrinkle is that the transform is a combination of affine
transforms (which I’m sure OpenGL handles just fine) with arbitrary
transforms such as log scaling or polar transformations. I assume this
would all have to be implemented as a vertex shader to get the
performance benefits of OpenGL. We could probably implement all of the
transforms built in to matplotlib (which cover a lot of cases), and then
just provide some slow “escape route” to handle arbitrary transforms
written in Numpy/Python, and for bonus points provide a hook for users
to add their own OpenGL transforms (just as it would have been necessary
to do with Javascript in the case of web browser rendering). But I bet
a lot of people would be happy as a start to just have the built-in
transforms working.
The last thing to raise is the case of very large data. When I was
investigating rendering in a web browser, there were pretty low limits
to the number of vertices I could keep hold of in the browser.
matplotlib has a “path simplification” algorithm to reduce the number of
vertices without changing the appearance of the plot, but of course
that’s dependant on the scale, so it has to be rerun every time the
scale changes. While path simplification may not be as necessary for
speed on the GPU, it may be necessary due to memory constraints.
Mike