On Fri, Jul 29, 2011 at 11:05 AM, Michael Droettboom <md...@stsci.edu>wrote:
> **
> Nicolas,
>
> I'm not sure how you've reached your conclusion.
>
> The 21,000 calls to Line2D.draw (i.e. 21 per frame) are easily explained
> since each grid line (or tick) is in fact a line.
>
> The 10,000 calls to Tick.draw (i.e. 10 per frame) are because there are 10
> tick labels.
>
> likewise for Text.draw etc. and on down the list.
>
> I don't see how any of these objects could be drawn without calling draw.
> ;) There actually already is caching that occurs rendering text, for
> example. None of these calls are strictly "useless".
>
> If animation speed is important, there are tricks in the examples/animation
> directory that show how to reuse the ticks from a previous draw and only
> update the data (i.e. eliminate many of these "useless" draw calls). But
> they are tricks -- they don't work for the general case of "anything in this
> plot may change at any time".
>
> But I think you are comparing apples to oranges in your speed comparison.
> You say a "do-nothing" loop in PyOpenGL runs at around 2000 fps, and a
> "do-nothing" loop in matplotlib runs about 100fps. But, of course, the
> matplotlib test case is actually doing a great deal even with the backend
> doing nothing -- it is doing all of the work of laying out the plot, which
> is the majority of time spent getting a plot to the screen. And that all
> work happens in Python -- its speed is what it is and is acceptable in many
> contexts -- but no backend work is going to improve what's going on in the
> core.
>
> I should warn you that previous attempts to speed up matplotlib using
> hardware acceleration have failed to produce much fruit because the backends
> actually do fairly little work by design in matplotlib. The actual act of
> rendering paths into pixels on screen (i.e. what happens in the backend) is
> a small fraction of the run time, even when using a software renderer (eg.
> Agg). Here's a useful benchmark that renders a plot a bunch of times to
> memory:
>
> import sys
> import matplotlib
> matplotlib.use(sys.argv[-1])
> from pylab import *
> import numpy
> plot(numpy.arange(int(sys.argv[-2])))
> for i in xrange(1000):
> draw()
>
> and the results (on my 2.33GHz Intel E6550):
>
> > time python test_backend_speed.py 3 agg
>
> real 0m15.211s
> user 0m15.009s
> sys 0m0.136s
>
> # Here "backend_pyglet" is the do-nothing backend you sent to the list in a
> previous e-mail
> > time python test_backend_speed.py 3 module://backend_pyglet
>
> real 0m14.038s
> user 0m13.713s
> sys 0m0.256s
>
> > time python test_backend_speed.py 100 agg
>
> real 0m23.038s
> user 0m22.845s
> sys 0m0.132s
>
> > time python test_backend_speed.py 100 module://backend_pyglet
>
> real 0m15.251s
> user 0m14.837s
> sys 0m0.304s
>
> So you see the actual work in the backend can be a fairly small fraction of
> the total runtime -- that gives one an idea of the upper bound on the speed
> improvement that any backend could make without digging into the matplotlib
> core and making improvements there.
>
> In fairness, my test is not measuring the time to (once rendering the plot)
> blit it to the screen. I suspect OpenGL will have an advantage there. It
> may even be possible as a mid-way solution to create an Agg/OpenGL backend
> that used Agg for rendering and OpenGL -- that's something that would be
> really useful just to have another nice cross-platform GUI backend.
>
> The other important thing to note about this benchmark is that as the size
> of the data increases, the proportion of time spent in the backend
> increases.
>
> I'm also worried (and I have no numbers to back this up) that a pyglet or
> PyOpenGL backend may actually be slower if the work to convert paths from
> matplotlib's path.Path format to the format understood by pyglet and/or
> PyOpenGL happens in Python, as your preliminary code backend_pyglet.py does
> in draw_path (i.e. looping over each vertex in a Python loop.) In the Agg
> backend, that happens in C++ on-the-fly without copying the data -- see
> src/path_converters.h. This code is exposed to Python through
> matplotlib._path.cleanup_path, but that does require copying memory, which
> for large data sets may be a limiting factor. So you may end up needing to
> write the backend in C++ to really beat the current Agg backend, but I'd
> love to be proven wrong.
>
> I hope this helps to better illustrate what you're seeing, and I don't mean
> to discourage you in implementing an OpenGL-based backend (which would be
> very nice to have for portability reasons among others). But I hope this
> also illustrates that if the end goal is simply to "go faster", this may be
> somewhat like putting racing tires on a car without replacing the engine.
>
> Cheers,
> Mike
>
>
Nicolas,
I would like to add to Mike's comments by making it clear why I am
interested in having OpenGL for matplotlib. It is not for speed. The last
time I checked, a good portion of time is actually spent on the axis tickers
and automatic limits. So, if speed is your goal, then that might be the
better place to look.
No, my main interest in OpenGL is to relax matplotlib's 2D limitation. At
the core of matplotlib is a 2D layering engine that was perfectly suited for
2D graphing. mplot3d then takes advantage of that layering feature to
hack-on 3D functionality. However, as has been noted many, many times, this
does not always produce correct results. I would love for the 2D layering
core to have some sort of logic where if the OpenGL backend is in use, and
if 3D art objects are detected, then bypass the dimension reduction that is
done in the layering engine and send the full 3D data over to OpenGL and let
it figure out the correct 2D projection.
However, I am not an OpenGL programmer and I wouldn't even know where to
start. That is why I am very happy to see someone give this another try.
Also, as a side note, in discussions with Ryan May (who did the previous
attempt at using pyglet), the main reason he discontinued development at
that time was because the text rendering in pyglet was very poor and not
anti-aliased. Do you have any indication if that has improved or not?
Ben Root
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
