Depending on the exact use case you can get pretty good mileage out of
blitting (See http://matplotlib.org/api/animation_api.html#funcanimation for
an explanation or how it is used in the widgets module).
The best way to make things faster is to just do less work :)
Tom
On Thu, Sep 21, 2017 at 5:14 PM Chris Barker wrote:
> On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda <
> f.faccend...@gmail.com> wrote:
>
>> I have to admit I already stumbled on VisPy while doing my research on
>> the web. Still, I've got a lot of code already working with *matplotlib*.
>> Indeed, not only I plot data with it, but i manage a lot of *mpl events*
>> to provide the users usefool tools, like lines picking, tooltips, lines
>> copy/paste, square selectors for multiple selections, context menu and so
>> on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While
>> at the beginning few lines were managed and noone complained, now that big
>> amout of data has to be displayed, the non-GPU core of the library is
>> starting to show its limits.
>>
>> Since matplotlib is a reference library for this kind of applications, I
>> thought it deserved an update in this direction.
>>
>
> Well, As I understand it, VisPY made some effort to be compatible with the
> MPL API -- but that is going to depend on how much you use the lower-level
> parts f the API -- things like the transform, etc. to take advantage of GPU
> rendering, all the transforms, etc needs to be pushed to the GPU, so the
> architecture (and API) needs to be quite different.
>
>
>> If anyone is willing to do so, I'm available to discuss possible
>> solutions and also provide any help I can give.
>>
>
> As Ben pointed out, and I was trying to make clear -- it really isn't a
> matter of "just" writing an OpenGL backend -- there really needs to be a
> major restructuring.
>
> And VisPy is pretty much that project. Whether it is feature complete,
> robust and maintained enough for your use-cases, I have no idea, but even
> if not -- you'll probably be better off contributing to that effort than
> starting all over with trying to make an GPU_based OPenGL back-end.
>
> However -- maybe there is another option:
>
> Taking full advantage of GPUs does require a full restructuring, but maybe
> there are other ways to get better performance -- for instance, optimizing
> the transform code, etc:
>
> Using the GPU with PyCuda or [what the heck is the name of the more
> general GPU-using lib??]
>
> using numba
>
> Maybe there is still room for Cython, etc
>
> In short, profiling MPL carefully, to see where the performance
> bottlenecks are:
>
> With modern hardware, actually rendering stuff is no longer the slow part
> of visualization. Rather, it's pushing data to the renderer, transforming
> data etc.
>
> This is why to take advantage of the GPU, you need to do the
> transformations, etc on the GPU -- which the MPL architecture doesn't make
> easy by dropping in a new back-end.
>
> Which is why VisPy built a new architecture from the bottom up.
>
> -CHB
>
>
> --
>
> 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
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
