<div dir="ltr">Depending on the exact use case you can get pretty good mileage out of blitting (See <a href="http://matplotlib.org/api/animation_api.html#funcanimation">http://matplotlib.org/api/animation_api.html#funcanimation</a> for an explanation or how it is used in the widgets module).  <div><br></div><div>The best way to make things faster is to just do less work :)<div><br></div><div>Tom</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 21, 2017 at 5:14 PM Chris Barker <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda <span dir="ltr"><<a href="mailto:f.faccenda86@gmail.com" target="_blank">f.faccenda86@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>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 <i>matplotlib</i>. Indeed, not only I plot data with it, but i manage a lot of <i>mpl events</i> 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 <b>embedded </b>on <i>wxpython </i>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.<br><br></div>Since matplotlib is a reference library for this kind of  applications, I thought it deserved an update in this direction.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div> If anyone is willing to do so, I'm available to discuss possible solutions and also provide any help I can give.<br></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>However -- maybe there is another option:</div><div><br></div><div>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:</div><div><br></div><div>Using the GPU with PyCuda or [what the heck is the name of the more general GPU-using lib??]</div><div><br></div><div>using numba</div><div><br></div><div>Maybe there is still room for Cython, etc....</div><div><br></div><div>In short, profiling MPL carefully, to see where the performance bottlenecks are:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Which is why VisPy built a new architecture from the bottom up.</div><div><br></div><div>-CHB</div><div><br></div><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra">-- <br><div class="m_6923138849016380942m_2958482640517411757gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            <a href="tel:(206)%20526-6959" value="+12065266959" target="_blank">(206) 526-6959</a>   voice<br>7600 Sand Point Way NE   <a href="tel:(206)%20526-6329" value="+12065266329" target="_blank">(206) 526-6329</a>   fax<br>Seattle, WA  98115       <a href="tel:(206)%20526-6317" value="+12065266317" target="_blank">(206) 526-6317</a>   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>
------------------------------------------------------------------------------<br>
Check out the vibrant tech community on one of the world's most<br>
engaging tech sites, Slashdot.org! <a href="http://sdm.link/slashdot" rel="noreferrer" target="_blank">http://sdm.link/slashdot</a>_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@lists.sourceforge.net" target="_blank">Matplotlib-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/matplotlib-devel</a><br>
</blockquote></div>