Some update on GL backend

Hi all,

I'm continuing experimenting various solution for a possible GL backend for matplotlib and I made some progress (but no integration yet).

You can check results (and experimenting yourself at various places, sorry for that):

Text : http://code.google.com/p/freetype-gl/
       http://code.google.com/p/freetype-py/

Images interpolation & 3D : http://code.google.com/p/glumpy/

Lines/Shapes : http://code.google.com/p/gl-agg/

The last experiments (gl-agg) were about high-quality lines and shapes. It seems OpenGL may offer pretty decent quality (IMHO) as you can see on the various screenshots that compare agg and opengl. demo-lines.py and a demo-circles.py show zooming/panning speed (mouse drag / scroll).

There are still some more work to, mainly concave polygons and bezier filled shapes.

However, the whole integration into matplotlib may require a lot of work since OpenGL technics may radically differ from their matplotlib counterpart in some case. For example, a grid is rendered using a single shader that manages internally all the lines and ticks. Another example is image interpolation that is done entirely on the graphic card (see glumpy).

Also, Don't be fooled by the speed of the current demo-lines.py and demo-circles.py because they don't offer the versatility of matplotlib.

At this point, I may lack time to write the actual integration into matplotlib and I may not know enough the internal matplotlib machinery. Maybe this could be a future project for next year / Google summer of code ? What do you think ?

Nicolas

Nicholas,

There's a word for people like you: 'Hero'.

The output, in my opinion, looks very nice. Personally, I don't see
myself using this for the two-dimensional stuff unless it's because I
need to quickly look at something (just like you mention on the glumpy
main page), but I think this is a winner for producing 3D plots. GL is a
champion when it comes to 3D rendering, a la MayaVI, VTK or Paraview and
the current mplot3d toolkit is using all of matplotlib's two dimensional
capabilities. I would love to have something like this that mplot3d can
hook into to produce publication-quality visualisations in
three-dimensional space.

I have no experience with the backend side of matplotlib, I just wanted
to say thank you for your effort :slight_smile:

···

On Wed, Aug 01, 2012 at 11:24:06AM +0200, Nicolas Rougier wrote:

Hi all,

I'm continuing experimenting various solution for a possible GL backend for matplotlib and I made some progress (but no integration yet).

You can check results (and experimenting yourself at various places, sorry for that):

Text : Google Code Archive - Long-term storage for Google Code Project Hosting.
       Google Code Archive - Long-term storage for Google Code Project Hosting.

Images interpolation & 3D : Google Code Archive - Long-term storage for Google Code Project Hosting.

Lines/Shapes : Google Code Archive - Long-term storage for Google Code Project Hosting.

The last experiments (gl-agg) were about high-quality lines and shapes. It seems OpenGL may offer pretty decent quality (IMHO) as you can see on the various screenshots that compare agg and opengl. demo-lines.py and a demo-circles.py show zooming/panning speed (mouse drag / scroll).

There are still some more work to, mainly concave polygons and bezier filled shapes.

However, the whole integration into matplotlib may require a lot of work since OpenGL technics may radically differ from their matplotlib counterpart in some case. For example, a grid is rendered using a single shader that manages internally all the lines and ticks. Another example is image interpolation that is done entirely on the graphic card (see glumpy).

Also, Don't be fooled by the speed of the current demo-lines.py and demo-circles.py because they don't offer the versatility of matplotlib.

At this point, I may lack time to write the actual integration into matplotlib and I may not know enough the internal matplotlib machinery. Maybe this could be a future project for next year / Google summer of code ? What do you think ?

Nicolas

--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Thanks. Apart from the speed, an OpenGL backend could be also useful for the ipython notebook using webgl (but I'm a total newbie at webgl).

Nicolas

···

On Aug 1, 2012, at 12:07 , Damon McDougall wrote:

On Wed, Aug 01, 2012 at 11:24:06AM +0200, Nicolas Rougier wrote:

Hi all,

I'm continuing experimenting various solution for a possible GL backend for matplotlib and I made some progress (but no integration yet).

You can check results (and experimenting yourself at various places, sorry for that):

Text : Google Code Archive - Long-term storage for Google Code Project Hosting.
      Google Code Archive - Long-term storage for Google Code Project Hosting.

Images interpolation & 3D : Google Code Archive - Long-term storage for Google Code Project Hosting.

Lines/Shapes : Google Code Archive - Long-term storage for Google Code Project Hosting.

The last experiments (gl-agg) were about high-quality lines and shapes. It seems OpenGL may offer pretty decent quality (IMHO) as you can see on the various screenshots that compare agg and opengl. demo-lines.py and a demo-circles.py show zooming/panning speed (mouse drag / scroll).

There are still some more work to, mainly concave polygons and bezier filled shapes.

However, the whole integration into matplotlib may require a lot of work since OpenGL technics may radically differ from their matplotlib counterpart in some case. For example, a grid is rendered using a single shader that manages internally all the lines and ticks. Another example is image interpolation that is done entirely on the graphic card (see glumpy).

Also, Don't be fooled by the speed of the current demo-lines.py and demo-circles.py because they don't offer the versatility of matplotlib.

At this point, I may lack time to write the actual integration into matplotlib and I may not know enough the internal matplotlib machinery. Maybe this could be a future project for next year / Google summer of code ? What do you think ?

Nicolas

Nicholas,

There's a word for people like you: 'Hero'.

The output, in my opinion, looks very nice. Personally, I don't see
myself using this for the two-dimensional stuff unless it's because I
need to quickly look at something (just like you mention on the glumpy
main page), but I think this is a winner for producing 3D plots. GL is a
champion when it comes to 3D rendering, a la MayaVI, VTK or Paraview and
the current mplot3d toolkit is using all of matplotlib's two dimensional
capabilities. I would love to have something like this that mplot3d can
hook into to produce publication-quality visualisations in
three-dimensional space.

I have no experience with the backend side of matplotlib, I just wanted
to say thank you for your effort :slight_smile:

--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Nicolas,

It is great to see that you have made some progress with glumpy! It is my hope that after the effort I have been making to refactorng the Axes class that I would then move on to studying glumpy to see how to bring that work into matplotlib. It is certainly will not be trivial. I like the idea of making it into a GSoC project. Maybe we can get NumFOCUS to support that effort?

Cheers!
Ben Root

···

On Wed, Aug 1, 2012 at 6:44 AM, Nicolas Rougier <Nicolas.Rougier@…922…> wrote:

Thanks. Apart from the speed, an OpenGL backend could be also useful for the ipython notebook using webgl (but I’m a total newbie at webgl).

Nicolas

I will also try to look at the GL backend again.

One of the main difficulty I see is to handle GPU memory properly. For example, to draw a line collection (using OpenGL) I first build a vertex buffer that is sent to the GPU and then offset/translate/rotate can be done locally/globally very efficiently without rebuilding the vertex buffer. In the template backend however, the "draw_path" function receives a path to be rendered and I need to ensure it is build only once and only applying transforms for subsequent calls. Also, Mike explained the overall situation very well (last year on this mailing list) regarding backend performances.

As for NumFOCUS, what kind of support do you expect ?

Nicolas

···

On Aug 1, 2012, at 16:15 , Benjamin Root wrote:

On Wed, Aug 1, 2012 at 6:44 AM, Nicolas Rougier <Nicolas.Rougier@...980....> wrote:

Thanks. Apart from the speed, an OpenGL backend could be also useful for the ipython notebook using webgl (but I'm a total newbie at webgl).

Nicolas

Nicolas,

It is great to see that you have made some progress with glumpy! It is my hope that after the effort I have been making to refactorng the Axes class that I would then move on to studying glumpy to see how to bring that work into matplotlib. It is certainly will not be trivial. I like the idea of making it into a GSoC project. Maybe we can get NumFOCUS to support that effort?

Cheers!
Ben Root