Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

[Benjamin R. <ben...@ou...>]

On Thu, Mar 7, 2013 at 10:12 AM, Michael Droettboom <md...@st...> wrote:

> 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
>
>
Just to voice what my main interest in an OpenGL backend is a chance to
move away from the layering approach of the matplotlib renderer to the
ability to specify three dimensional data to plot.  Performance is a nice
side-benefit, certainly, but breaking out our low-level assumptions of how
we plot would be refreshing.

Ben Root