Re: [matplotlib-devel] Kivy backend

[Chris B. <chr...@no...>]

On Fri, Mar 13, 2015 at 10:21 AM, Benjamin Root <ben...@ou...> 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 <
> Nic...@in...> 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...@ou...> 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 <
>> cyr...@gm...> 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
>> > Mat...@li...
>> > 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
>> > Mat...@li...
>> > 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

Chr...@no...