On Thu, Mar 7, 2013 at 10:12 AM, Michael Droettboom <md...@stsci.edu> 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
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
