Hello , I am a novice gsoc aspirant and I want to write a backend for kivy, I read some of the other conversations on the mailing list and I know about the template you guys provide but I am having trouble getting started, can you please help me get up-to speed. I would be great help if you could tell me what all I need to know of matplotlib to write a good backend.
Thank You
Achyut Rastogi
Achyut,
Thank your for your interest, mpl on touch devices sounds super cool!
The easiest course is probably to develop a backend modeled after the {qt,wx,gtk}Agg backends which embed an Agg backend into the gui framework of choice. In those cases we rely on Agg to handle the mpl specific drawing tasks and then embed the resulting bitmap into the GUI. A majority of the work in the gui backends deals window/widget creation and the plumbing required to convert interaction events from the GUI into the internal events mpl uses.
Tom
On Sat, Mar 7, 2015 at 4:15 PM Achyut Rastogi <rastogiachyut@…149…> wrote:
Hello , I am a novice gsoc aspirant and I want to write a backend for kivy, I read some of the other conversations on the mailing list and I know about the template you guys provide but I am having trouble getting started, can you please help me get up-to speed. I would be great help if you could tell me what all I need to know of matplotlib to write a good backend.
Thank You
Achyut Rastogi
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@…1041…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Thank your for your interest, mpl on touch devices sounds super cool!
Indeed!
The easiest course is probably to develop a backend modeled after the
{qt,wx,gtk}Agg backends which embed an Agg backend into the gui framework
of choice. In those cases we rely on Agg to handle the mpl specific
drawing tasks and then embed the resulting bitmap into the GUI.
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."
HTH,
-Chris
On Sat, Mar 7, 2015 at 4:17 PM, Thomas Caswell <tcaswell@...149...> wrote:
A majority of the work in the gui backends deals window/widget creation
and the plumbing required to convert interaction events from the GUI into
the internal events mpl uses.Tom
On Sat, Mar 7, 2015 at 4:15 PM Achyut Rastogi <rastogiachyut@...149...> > wrote:
Hello , I am a novice gsoc aspirant and I want to write a backend for
kivy, I read some of the other conversations on the mailing list and I know
about the template you guys provide but I am having trouble getting
started, can you please help me get up-to speed. I would be great help if
you could tell me what all I need to know of matplotlib to write a good
backend.
Thank You
Achyut Rastogi
------------------------------------------------------------
------------------
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
matplotlib-devel List Signup and Options------------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
--
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.Barker@...236...
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
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.
+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.rossant@…149…> wrote:
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
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.
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.”
I don’t think it would work like the other backends. Last time I checked, the MPL backend system would not let us achieve high performance. Currently we use Jake Vanderplas’ mplexporter system that was developed for mpld3.
Eventually, I guess we could expose the same interface as mpld3, i.e. replace plt.show() by something like vispy.show(). This would display a matplotlib figure with VisPy (which supports Qt, wx, and other GUI toolkits) instead of one of matplotlib’s backends. In the notebook, something like vispy.enable_notebook() could replace matplotlib’s inline PNG by a dynamic WebGL canvas.
2015-03-13 17:33 GMT+01:00 Benjamin Root <ben.root@…553…>:
+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.rossant@…149…> wrote:
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
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.
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.”
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 Glumpy gallery)
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.root@...553...> 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.rossant@...716......> 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
"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
matplotlib-devel List Signup and Options------------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options
MEP 25 is working towards providing a way to serialize the contents of a figure in a more controlled way. The main target of this is saving/reopening figures and export to bokeh/plotly/d3, but I think this would also work well for exporting everything off to an opengl backend.
Tom
On Fri, Mar 13, 2015 at 1:09 PM Nicolas P. Rougier <Nicolas.Rougier@…922…> 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.root@…553…> 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.rossant@…149…> 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
“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@…1041…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@…1041…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@…1041…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Quite honestly, I am not all that concerned about speed (at least, I am not talking about achieving gaming level performance). I am most concerned about compatibility, quality of the image rendering, quality of the text rendering, and consistency across platforms. Probably what I am most interested in from OpenGL is its transforms stack. 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.Rougier@…982…> 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.root@…553…> 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.rossant@…149…> 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
“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
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
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
By speed I meant to be able to render "big" plot (like a million point scatter plot or having 10 000 isolines, etc.)
Concerning output quality, I think we're almost done. We have antialiases lines, markers and polygons (equivalent to agg), 2D agg-quality text (same techniques) and 3D decent text quality (see http://glumpy.github.io/_static/screenshots/lorenz.png). It is now a matter of integrating all this together and of course to debug it...
Nicolas
On 13 Mar 2015, at 18:21, Benjamin Root <ben.root@...553...> wrote:
Quite honestly, I am not all that concerned about speed (at least, I am not talking about achieving gaming level performance). I am most concerned about compatibility, quality of the image rendering, quality of the text rendering, and consistency across platforms. Probably what I am most interested in from OpenGL is its transforms stack. 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.Rougier@...924...22...> 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 Glumpy gallery)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.root@...553...> 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.rossant@...746...49...> 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
>
> "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
> matplotlib-devel List Signup and Options
>
>
> ------------------------------------------------------------------------------
> 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
> matplotlib-devel List Signup and Options
2015-03-13 18:21 GMT+01:00 Benjamin Root <ben.root@...553...>:
Quite honestly, I am not all that concerned about speed (at least, I am
not talking about achieving gaming level performance). I am most concerned
about compatibility, quality of the image rendering, quality of the text
rendering, and consistency across platforms. Probably what I am most
interested in from OpenGL is its transforms stack. 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.
Modern shader-based OpenGL no longer has transform stacks: we need to
implement GPU transforms ourselves. This is all handled by VisPy, and we
have total control on that architecture. We do want to support 2D and 3D
simultaneously. We are still in the process of designing this architecture
though, and I guess it would certainly make sense for matplotlib devs to be
involved in the discussions...
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
On Fri, Mar 13, 2015 at 10:21 AM, Benjamin Root <ben.root@...553...> wrote:
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.Rougier@...922...> 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 Glumpy gallery)But we'll try to use matplotlib public api such that things will be
mostly transparent for the userNicolas
> On 13 Mar 2015, at 17:33, Benjamin Root <ben.root@...553...> 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.rossant@...149...> 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
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
> matplotlib-devel List Signup and Options
>
>
>
------------------------------------------------------------------------------
> 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
> matplotlib-devel List Signup and Options
--
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.Barker@...236...
Don't overestimate the cost of the data transfer, at least for non-millions
of points. Even years ago, just doing basic opengl plotting (no
sophisticated use of on-GPU memory), was a big win.
The other win for mpl + opengl is giving a real rasterizer and depth buffer
for the mpl3d package, which is hampered by the per-artist z-ordering.
Ryan
On Fri, Mar 13, 2015 at 12:53 PM, Chris Barker <chris.barker@...236...> wrote:
On Fri, Mar 13, 2015 at 10:21 AM, Benjamin Root <ben.root@...553...> 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.
--
Ryan May
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.
Exactly. Note that pushing data on the GPU is not that slow: in one
second, you can send hundreds of millions of points on a modern GPU.
However it would be a bit slow to send large amounts of data at every
frame.
GPU-based transformations are extremely fast, and you have full
control on how they're implemented; in the end, it's just arbitrary C
code that runs on the GPU on a per-vertex or per-pixel basis.
Exactly. Note that pushing data on the GPU is not that slow:
No -- and something has to be pushed to the video card at some point anyway.
But my experience is that if you need to push the data to the CPU,
that pretty much overwhelms the advantages you get by rendering on the
GPU.
And OpenGL only supports simple primitives -- so it's substantially
more a pain to do something as sole as render a filled polygon, let
alone a spline.
And yes, back In the day, it was faster to render on the video card,
but CPUs have gotten a lot faster, and memory busses not so much.
But whatever, I think we all agree that pushing the transformations to
the GPU is the big win.
-CHB
On Mar 13, 2015, at 12:50 PM, Cyrille Rossant <cyrille.rossant@...149...> wrote:
in one
second, you can send hundreds of millions of points on a modern GPU.
However it would be a bit slow to send large amounts of data at every
frame.GPU-based transformations are extremely fast, and you have full
control on how they're implemented; in the end, it's just arbitrary C
code that runs on the GPU on a per-vertex or per-pixel basis.
Hello,
I am having trouble following the instructions given here → https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/backends/backend_template.py#L16 it feels like the code was refractored (changed?) and those instructions never updated?
On Sun, Mar 15, 2015 at 6:23 AM, Chris Barker - NOAA Federal <chris.barker@…236…> wrote:
On Mar 13, 2015, at 12:50 PM, Cyrille Rossant <cyrille.rossant@…149…> wrote:
Exactly. Note that pushing data on the GPU is not that slow:
No – and something has to be pushed to the video card at some point anyway.
But my experience is that if you need to push the data to the CPU,
that pretty much overwhelms the advantages you get by rendering on the
GPU.
And OpenGL only supports simple primitives – so it’s substantially
more a pain to do something as sole as render a filled polygon, let
alone a spline.
And yes, back In the day, it was faster to render on the video card,
but CPUs have gotten a lot faster, and memory busses not so much.
But whatever, I think we all agree that pushing the transformations to
the GPU is the big win.
-CHB
in one
second, you can send hundreds of millions of points on a modern GPU.
However it would be a bit slow to send large amounts of data at every
frame.
GPU-based transformations are extremely fast, and you have full
control on how they’re implemented; in the end, it’s just arbitrary C
code that runs on the GPU on a per-vertex or per-pixel basis.
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
Giving it a cursory glance, I think it’s mostly current.� Is there
something specific that isn’t working for you?
Mike
On 03/23/2015 08:09 AM, Achyut Rastogi
wrote:
Hello,
I am having trouble following the instructions given here -->https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/backends/backend_template.py#L16 �
it feels like the code was refractored (changed?) and those
instructions never updated?
On Sun, Mar 15, 2015 at 6:23 AM, ChrisBarker - NOAA Federal <chris.barker@…236…>
wrote:On Mar 13, 2015, at 12:50 PM, Cyrille Rossant<cyrille.rossant@…149… >
wrote:> Exactly. Note that pushing data on the GPU is notthat slow:
No -- and something has to be pushed to the videocard at some point anyway.
But my experience is that if you need to push the data tothe CPU,
that pretty much overwhelms the advantages you get byrendering on the
GPU. And OpenGL only supports simple primitives -- so it'ssubstantially
more a pain to do something as sole as render a filledpolygon, let
alone a spline. And yes, back In the day, it was faster to render on thevideo card,
but CPUs have gotten a lot faster, and memory busses not somuch.
But whatever, I think we all agree that pushing thetransformations to
the GPU is the big win. -CHB > in one > second, you can send hundreds of millions of pointson a modern GPU.
> However it would be a bit slow to send largeamounts of data at every
> frame. > > GPU-based transformations are extremely fast, andyou have full
> control on how they're implemented; in the end,it’s just arbitrary C
> code that runs on the GPU on a per-vertex orper-pixel basis.
Dive into the World of Parallel Programming The GoParallel Website, sponsored
by Intel and developed in partnership with SlashdotMedia, is your hub for all
things parallel software development, from weeklythought leadership blogs to
news, videos, case studies, tutorials and more. Take alook and join the
conversation now. [http://goparallel.sourceforge.net/](http://goparallel.sourceforge.net/) _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net [https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](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._______________________________________________ Matplotlib-devel mailing list
http://goparallel.sourceforge.net/Matplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel
No, sorry that was probably a mistake on my part, I thought that I would find the list of backends in init.py instead of https://github.com/rastogiachyut/matplotlib/blob/master/lib/matplotlib/rcsetup.py#L31
On Tue, Mar 24, 2015 at 10:45 PM, Michael Droettboom <mdroe@…31…> wrote:
Giving it a cursory glance, I think it's mostly current. Is theresomething specific that isn’t working for you?
Mike On 03/23/2015 08:09 AM, Achyut Rastogiwrote:
Hello,
I am having trouble following the instructions given here -->https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/backends/backend_template.py#L16
it feels like the code was refractored (changed?) and those
instructions never updated?
------------------------------------------------------------------------------ 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/](http://goparallel.sourceforge.net/)_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net [https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](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
On Sun, Mar 15, 2015 at 6:23 AM, Chris
Barker - NOAA Federal <chris.barker@…236…>
wrote:
On Mar 13, 2015, at 12:50 PM, Cyrille Rossant<cyrille.rossant@…149… >
wrote:> Exactly. Note that pushing data on the GPU is notthat slow:
No -- and something has to be pushed to the videocard at some point anyway.
But my experience is that if you need to push the data tothe CPU,
that pretty much overwhelms the advantages you get byrendering on the
GPU. And OpenGL only supports simple primitives -- so it'ssubstantially
more a pain to do something as sole as render a filledpolygon, let
alone a spline. And yes, back In the day, it was faster to render on thevideo card,
but CPUs have gotten a lot faster, and memory busses not somuch.
But whatever, I think we all agree that pushing thetransformations to
the GPU is the big win. -CHB > in one > second, you can send hundreds of millions of pointson a modern GPU.
> However it would be a bit slow to send largeamounts of data at every
> frame. > > GPU-based transformations are extremely fast, andyou have full
> control on how they're implemented; in the end,it’s just arbitrary C
> code that runs on the GPU on a per-vertex orper-pixel basis.
Dive into the World of Parallel Programming The GoParallel Website, sponsored
by Intel and developed in partnership with SlashdotMedia, is your hub for all
things parallel software development, from weeklythought leadership blogs to
news, videos, case studies, tutorials and more. Take alook and join the
conversation now. [http://goparallel.sourceforge.net/](http://goparallel.sourceforge.net/) _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net [https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)