On Thu, Mar 7, 2013 at 9:24 AM, Benjamin Root <ben.r...@ou.edu> wrote: > > > 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.
I agree here. I would certainly benefit from this. I'm really lost when it comes to how to could optimise our rendering, especially with text rendering being extremely slow at present. I am, however, a little concerned we may be reinventing the wheel here with useful tools that already exist for 3d rendering. Paraview and MayaVi come to mind. > > 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 > -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 ------------------------------------------------------------------------------ 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
