On Fri, Mar 13, 2015 at 10:21 AM, Benjamin Root <ben.r...@ou.edu> wrote:
> Probably what I am most interested in from OpenGL is its transforms stack.
>
OpenGL can't do anything with transforms that you couldn't do in python (or
C, or Cython). What it can do is push the transform computations to the
GPU(s) -- making for monstrously faster performance.
This is the "problem" with the current MPL architecture. It does all the
transforming outside of the back-ends, and assumes that the backends can
only render in 2-d pixel coordinates.
If we can re-factor to push the transforms to the back-end, most of them
could use the same generic code, but you'd have the option of the back-end
providing the transforms, which would buy you a LOT with Open GL, and could
maybe by you some with, say, wxAgg, as you could put the transforms in
C/C++ perhaps more efficiently.
Note that with OPenGL in general, its the transforming that buys you
performance -- when you push brand new data to be rendered, it takes a lot
of time to push that data to the video card, so drawing the first time
doesn't buy you much. But if you need to re-render that same data in a
different view, say zooming in or out, etc, then GL can fly -- if that
transformation can be done on the GPU.
As far as I understand it, that's what vispy is doing.
-CHB
> While matplotlib's transforms stack is fantastic, it is inherently limited
> to 2D operations. Upgrading the transforms stack in some way would be huge
> thing to me.
>
> On Fri, Mar 13, 2015 at 1:08 PM, Nicolas P. Rougier <
> nicolas.roug...@inria.fr> wrote:
>
>>
>> It might be difficult to stick to matplotlib architecture and still
>> benefit from OpenGL speed.
>> There are a lot of GL techniques that speed up things a lot but are are
>> not really compatible.
>>
>> For example, isolines, quiver plots, image interpolations and most
>> transformations can be handled directly by the GPU
>> (see http://glumpy.github.io/gallery.html)
>>
>> But we'll try to use matplotlib public api such that things will be
>> mostly transparent for the user
>>
>> Nicolas
>>
>> > On 13 Mar 2015, at 17:33, Benjamin Root <ben.r...@ou.edu> wrote:
>> >
>> > +1 on an OpenGL backend! Especially if I can off-load a lot of mplot3d
>> stuff to it! Does vispy have any plans to eventually bring that into
>> mainline matplotlib, or does it break too much with the standard set of
>> backends to make sense in matplotlib (or maybe it is too much of a
>> maintenance/packaging burden?)
>> >
>> > Ben Root
>> >
>> > On Fri, Mar 13, 2015 at 12:12 PM, Cyrille Rossant <
>> cyrille.ross...@gmail.com> wrote:
>> > Kivy is all built on OpenGL, so it would probably be pretty
>> straightforward to generate teh image with AGG, then dump it to the screen
>> as an OpenGL texture. But it would be a bit sad to not take advantage of
>> OpenGL at all in that process. (and getting AGG to work with Kivy may be
>> less than trivial...)
>> >
>> > Note that vector graphics in OpenGL is a serious pain, but maybe Kivy
>> has some stuff to help?
>> >
>> > Also, the MPL back-end structure wasn't designed to push much of the
>> transforming, etc to the back -end, which is too bad, as that's what OpenGL
>> does well.
>> >
>> > But I'd still take a look at the work done to make a real OpenGL
>> back-end -- not sure how far that got, but worth a look.
>> >
>> > Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe
>> not! form teh vispy docs:
>> >
>> > "Vispy now ships a very basic and experimental OpenGL backend for
>> matplotlib."
>> >
>> >
>> > Yes, and we plan to work on this backend in the next few months. We
>> might have a couple of GSoC students working partly on the OpenGL MPL
>> backend and possibly on Kivy integration.
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> > by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> > things parallel software development, from weekly thought leadership
>> blogs to
>> > news, videos, case studies, tutorials and more. Take a look and join the
>> > conversation now. http://goparallel.sourceforge.net/
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Matplotlib-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> > by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> > things parallel software development, from weekly thought leadership
>> blogs to
>> > news, videos, case studies, tutorials and more. Take a look and join the
>> > conversation now.
>> http://goparallel.sourceforge.net/_______________________________________________
>> > Matplotlib-devel mailing list
>> > Matplotlib-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
