matplotlib-devel

[matplotlib-devel] GSOC 2013 (Google Summer Of Code)

[Nicolas R. <Nic...@in...>]

Hi all,

Are there any ongoing project for GSOC 2013 ? I would like to propose something around a GL backend but I'm not still sure OpenGL "philosophy" is compatible with current matplotlib design and any project would require co-mentoring with a matplotlib devel guru. There is a lot of experienced people around (Luke Campagnola, Cyrille Rossant, Almar Klein to name a few) who can help on the GL part and we're also currently trying to design together a common low-level API that may definitely help for the GL backend. What do you think ? Do we need first to make sure a GL backend make any sense at all before going further ?


Here is a small set of GL experiments I did recently that make me thinks it should be possible to come up with something nice and fast: https://github.com/rougier/gl-agg


Some movies for those who don't want to test: 

http://www.youtube.com/watch?v=T010zMtorAk
http://www.youtube.com/watch?v=iFwEzV9Pw-4




Nicolas

Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

[Michael D. <md...@st...>]

I'm not aware of any discussion about participating in GSoC this year, 
though I am open to the idea.  I was involved as a mentor a few years 
ago, but I wasn't terribly involved in the administrative side, so I 
don't know what's involved.  I think then we did it under the umbrella 
of the PSF.

I'd be interested in exploring a GL backend further.  What, from 10,000 
m, is the main impedence mismatch between the current matplotlib backend 
design and OpenGL rendering?

Mike

On 03/07/2013 03:39 AM, Nicolas Rougier wrote:
>
> Hi all,
>
> Are there any ongoing project for GSOC 2013 ? I would like to propose something around a GL backend but I'm not still sure OpenGL "philosophy" is compatible with current matplotlib design and any project would require co-mentoring with a matplotlib devel guru. There is a lot of experienced people around (Luke Campagnola, Cyrille Rossant, Almar Klein to name a few) who can help on the GL part and we're also currently trying to design together a common low-level API that may definitely help for the GL backend. What do you think ? Do we need first to make sure a GL backend make any sense at all before going further ?
>
>
> Here is a small set of GL experiments I did recently that make me thinks it should be possible to come up with something nice and fast: https://github.com/rougier/gl-agg
>
>
> Some movies for those who don't want to test:
>
> http://www.youtube.com/watch?v=T010zMtorAk
> http://www.youtube.com/watch?v=iFwEzV9Pw-4
>
>
>
>
> Nicolas
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

[Nicolas R. <Nic...@in...>]

Indeed, you analyzed/explained the overall situation very well in your blog post: http://mdboom.github.com/blog/2012/08/06/matplotlib-client-side/


OpenGL can make things very fast as long as there is not too many transfer between CPU/GPU memory. Once the data is within the GPU, most transformations (offset/translate/scale/rotate/interpolation/etc) can be made entirely on the GPU side. In the template backend however, the "draw_path" function (for example) receives a path to be rendered and I would need to ensure it is build only once and only applying transforms for subsequent calls.

At least it is my understanding of the matplotlib machinery but I may be wrong.


Nicolas






On Mar 7, 2013, at 15:36 , Michael Droettboom wrote:

> I'm not aware of any discussion about participating in GSoC this year, 
> though I am open to the idea.  I was involved as a mentor a few years 
> ago, but I wasn't terribly involved in the administrative side, so I 
> don't know what's involved.  I think then we did it under the umbrella 
> of the PSF.
> 
> I'd be interested in exploring a GL backend further.  What, from 10,000 
> m, is the main impedence mismatch between the current matplotlib backend 
> design and OpenGL rendering?
> 
> Mike
> 
> On 03/07/2013 03:39 AM, Nicolas Rougier wrote:
>> 
>> Hi all,
>> 
>> Are there any ongoing project for GSOC 2013 ? I would like to propose something around a GL backend but I'm not still sure OpenGL "philosophy" is compatible with current matplotlib design and any project would require co-mentoring with a matplotlib devel guru. There is a lot of experienced people around (Luke Campagnola, Cyrille Rossant, Almar Klein to name a few) who can help on the GL part and we're also currently trying to design together a common low-level API that may definitely help for the GL backend. What do you think ? Do we need first to make sure a GL backend make any sense at all before going further ?
>> 
>> 
>> Here is a small set of GL experiments I did recently that make me thinks it should be possible to come up with something nice and fast: https://github.com/rougier/gl-agg
>> 
>> 
>> Some movies for those who don't want to test:
>> 
>> http://www.youtube.com/watch?v=T010zMtorAk
>> http://www.youtube.com/watch?v=iFwEzV9Pw-4
>> 
>> 
>> 
>> 
>> Nicolas
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

[Michael D. <md...@st...>]

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

On 03/07/2013 09:50 AM, Nicolas Rougier wrote:
>
> Indeed, you analyzed/explained the overall situation very well in your blog post: http://mdboom.github.com/blog/2012/08/06/matplotlib-client-side/
>
>
> OpenGL can make things very fast as long as there is not too many transfer between CPU/GPU memory. Once the data is within the GPU, most transformations (offset/translate/scale/rotate/interpolation/etc) can be made entirely on the GPU side. In the template backend however, the "draw_path" function (for example) receives a path to be rendered and I would need to ensure it is build only once and only applying transforms for subsequent calls.
>
> At least it is my understanding of the matplotlib machinery but I may be wrong.
>
>
> Nicolas
>
>
>
>
>
>
> On Mar 7, 2013, at 15:36 , Michael Droettboom wrote:
>
>> I'm not aware of any discussion about participating in GSoC this year,
>> though I am open to the idea.  I was involved as a mentor a few years
>> ago, but I wasn't terribly involved in the administrative side, so I
>> don't know what's involved.  I think then we did it under the umbrella
>> of the PSF.
>>
>> I'd be interested in exploring a GL backend further.  What, from 10,000
>> m, is the main impedence mismatch between the current matplotlib backend
>> design and OpenGL rendering?
>>
>> Mike
>>
>> On 03/07/2013 03:39 AM, Nicolas Rougier wrote:
>>> Hi all,
>>>
>>> Are there any ongoing project for GSOC 2013 ? I would like to propose something around a GL backend but I'm not still sure OpenGL "philosophy" is compatible with current matplotlib design and any project would require co-mentoring with a matplotlib devel guru. There is a lot of experienced people around (Luke Campagnola, Cyrille Rossant, Almar Klein to name a few) who can help on the GL part and we're also currently trying to design together a common low-level API that may definitely help for the GL backend. What do you think ? Do we need first to make sure a GL backend make any sense at all before going further ?
>>>
>>>
>>> Here is a small set of GL experiments I did recently that make me thinks it should be possible to come up with something nice and fast: https://github.com/rougier/gl-agg
>>>
>>>
>>> Some movies for those who don't want to test:
>>>
>>> http://www.youtube.com/watch?v=T010zMtorAk
>>> http://www.youtube.com/watch?v=iFwEzV9Pw-4
>>>
>>>
>>>
>>>
>>> Nicolas
>>> ------------------------------------------------------------------------------
>>> 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
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

[Benjamin R. <ben...@ou...>]

On Thu, Mar 7, 2013 at 10:12 AM, Michael Droettboom <md...@st...> 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.

Ben Root

Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

[Damon M. <dam...@gm...>]

On Thu, Mar 7, 2013 at 9:24 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Thu, Mar 7, 2013 at 10:12 AM, Michael Droettboom <md...@st...> 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
> Mat...@li...
> 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

Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

[Michael D. <md...@st...>]

On 03/07/2013 12:45 PM, Damon McDougall wrote:
> I'm really lost when it comes to how to could optimise our rendering, 
> especially with text rendering being extremely slow at present.

Let's put some benchmarks together for this.  There's a lot of 
optimizations to the text rendering in the Agg backend already (caching 
pre-rendered text etc.), so if there's anything more to be done, we 
should get to the bottom of it.

Mike