Re: [matplotlib-devel] Native backend for Mac OS X
On Tue, Dec 30, 2008 at 10:57 AM, John Hunter jdh2...@gmail.com wrote: On Fri, Dec 26, 2008 at 8:40 AM, Michiel de Hoon mjldeh...@yahoo.com wrote: I have written such a function for the qt4 backend; see patch #2468809 at https://sourceforge.net/tracker/index.php?func=detailaid=2468809group_id=80706atid=560722 I am not a big qt4 user, so it would be good if somebody else could look at this patch before adding it to the trunk. I would like to apply this patch, but I am not a qt user either, so if someone could test this and get back to us, that would be great. Never had any luck getting a tester, so I went ahead and committed this to the trunk. I should probably get a working qt backend for testing on one of the machines I use JDH -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
On Sat, Jan 10, 2009 at 3:09 PM, John Hunter jdh2...@gmail.com wrote: On Tue, Dec 30, 2008 at 10:57 AM, John Hunter jdh2...@gmail.com wrote: On Fri, Dec 26, 2008 at 8:40 AM, Michiel de Hoon mjldeh...@yahoo.com wrote: I have written such a function for the qt4 backend; see patch #2468809 at https://sourceforge.net/tracker/index.php?func=detailaid=2468809group_id=80706atid=560722 I am not a big qt4 user, so it would be good if somebody else could look at this patch before adding it to the trunk. I would like to apply this patch, but I am not a qt user either, so if someone could test this and get back to us, that would be great. Never had any luck getting a tester, so I went ahead and committed this to the trunk. I should probably get a working qt backend for testing on one of the machines I use I'm sorry John, I didnt see your original request for testing. I tried running the following with interactive on and off: from pylab import * import numpy figure() x=numpy.arange(20) y=1+x**2 n = 4 for i in range(n*n): subplot(n,n,i+1) bar(x,y,log=True) xlim(-5,25) ylim(1,1e4) I didnt notice any significant diffference in speed in the two modes with the qt4agg backend, and the figures looked fine. Is there anything else I should be looking for? Darren -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
On Sat, Jan 10, 2009 at 2:49 PM, Darren Dale dsdal...@gmail.com wrote: Never had any luck getting a tester, so I went ahead and committed this to the trunk. I should probably get a working qt backend for testing on one of the machines I use I'm sorry John, I didnt see your original request for testing. I tried running the following with interactive on and off: I didnt notice any significant diffference in speed in the two modes with the qt4agg backend, and the figures looked fine. Is there anything else I should be looking for? No, that should do it -- thanks for taking a look. JDH -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
On Fri, Dec 26, 2008 at 8:40 AM, Michiel de Hoon mjldeh...@yahoo.com wrote: I have written such a function for the qt4 backend; see patch #2468809 at https://sourceforge.net/tracker/index.php?func=detailaid=2468809group_id=80706atid=560722 I am not a big qt4 user, so it would be good if somebody else could look at this patch before adding it to the trunk. I would like to apply this patch, but I am not a qt user either, so if someone could test this and get back to us, that would be great. JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
Could you post the script you are using to do the profiling? This is the code that I was using from pylab import * import numpy figure() x=numpy.arange(20) y=1+x**2 n = 4 for i in range(n*n): subplot(n,n,i+1) bar(x,y,log=True) xlim(-5,25) ylim(1,1e4) The call to subplot/plot/bar should not trigger a draw, unless interactive is set to True I was doing the profiling with interactive set to True (both for the Agg backends and for the Mac OS X native backend). With interactive set to False, I don't see any significant speed difference between Agg and the native backend. Interactive is not the best word, but it is the rc parameter meaning you are using mpl from the interactive prompt and want every pyplot command to update the plot. If the macosx backend is not doing this it should. In its current form, the MacOSX backend assumes that mpl is being used from the interactive prompt and the plot is updated whenever there are no further Python commands (in other words, when Python is waiting for the user to type in the next Python command). Maybe this is a naive question, but why would a user want every pyplot command to update the plot? --Michiel. -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
The interactive backends (wx, tk, gtk) all handle draw_idle in a way which delays the drawing until there are no more commands to run. By changing draw_if_interactive to use draw_idle instead of draw, wouldn't this automatically smooth over the performance issues without the user having to toggle interactive in their scripts? I just tried this approach with the tkagg and gtk backends, and indeed, this does solve the performance issue in interactive mode. --Michiel. -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
On Fri, Dec 19, 2008 at 9:07 AM, Paul Kienzle paul.kien...@nist.gov wrote: Interactive is not the best word, but it is the rc parameter meaning you are using mpl from the interactive prompt and want every pyplot command to update the plot. If the macosx backend is not doing this it should. If tkagg is issuing draw commands on pyplot commands when interactive is False, it is a bug that we should be able to fix. The interactive backends (wx, tk, gtk) all handle draw_idle in a way which delays the drawing until there are no more commands to run. This seems like a reasonable change and I have added it to the trunk. It would be nice to get a canvas.draw_idle on the qt backend, so perhaps Darren you can add this to your list if you get some free time. JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
On Fri, Dec 19, 2008 at 2:20 AM, Michiel de Hoon mjldeh...@yahoo.com wrote: This looks great -- in particular I am intrigued by the final timing results which show your backend 12 times faster than tkagg. I am not sure where this speedup is coming from -- do you have some ideas? In this example, I am drawing 16 subplots in a 4x4 grid. With Tkagg, I am noticing that the first few subplots appear quickly, but subsequent subplots get slower and slower. I think that this is due to how the event loop works. In my understanding, tkagg redraws the window when a subplot is added. So to draw subplot 16, tkagg also needs to redraw subplots 1..15, causing the progressive slowdown. The native backend draws all 16 at once, and draws each of them only once. Using plot() instead of bar() doesn't really make a difference; the same slowdown happens there with the agg backends. Could you post the script you are using to do the profiling? The call to subplot/plot/bar should not trigger a draw, unless interactive is set to True http://matplotlib.sourceforge.net/users/shell.html Interactive is not the best word, but it is the rc parameter meaning you are using mpl from the interactive prompt and want every pyplot command to update the plot. If the macosx backend is not doing this it should. If tkagg is issuing draw commands on pyplot commands when interactive is False, it is a bug that we should be able to fix. Thanks, JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
On Dec 19, 2008, at 7:52 AM, John Hunter wrote: Could you post the script you are using to do the profiling? The call to subplot/plot/bar should not trigger a draw, unless interactive is set to True http://matplotlib.sourceforge.net/users/shell.html Interactive is not the best word, but it is the rc parameter meaning you are using mpl from the interactive prompt and want every pyplot command to update the plot. If the macosx backend is not doing this it should. If tkagg is issuing draw commands on pyplot commands when interactive is False, it is a bug that we should be able to fix. The interactive backends (wx, tk, gtk) all handle draw_idle in a way which delays the drawing until there are no more commands to run. By changing draw_if_interactive to use draw_idle instead of draw, wouldn't this automatically smooth over the performance issues without the user having to toggle interactive in their scripts? - Paul -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
Hi Michiel, +1 to Chris Barker's request for information on where Agg makes extra calls to draw(). The 20% speedup in scatter performance is nice, and is clearly related to Agg. Any idea why the pcolormesh example is so much slower in Mac OS X than TkAgg? Thanks for your continued work on this. -Eric On Wed, Dec 17, 2008 at 5:52 AM, John Hunter jdh2...@gmail.com wrote: Hi Michiel, This looks great -- in particular I am intrigued by the final timing results which show your backend 12 times faster than tkagg. I am not sure where this speedup is coming from -- do you have some ideas? Because you are creating lots-o-subplots in that example, there is a lot of overhead at the python layer (many axes, many ticks, etc) so I don't see how a faster backend could generate such a significant improvement. What kind of timings do you see if you issue a plot rather than bar call in that example? One thing about bar in particular is that we draw lots of separate rectangles, each with thie own gc, and it has been on my wishlist for some time to do this as a collection. If you are handling gc creation, etc, in C, that may account for a big part of the difference. Since the new macosx backend was released in 0.98.5, I also need to decide whether this patch belongs on the branch, and hence will get pushed out as early as today in a bugfix release when some changes JJ and Michael are working on are ready, or the trunk, in which case it could be months. In favor of the trunk: this is more of a feature enhancement than a bugfix, and patches to the branch should be bugfixes with an eye to stability of the released code, though a good argument could be made that this is a bugfix. In favor of the branch: it is brand new code advertised as beta in 0.98.5 and so it is unlikely that anyone is using it seriously yet, and since it is beta, we should get as much of it out there ASAP so folks can test and pound on it. I'm in favor of branch, but I wanted to bring this up here since we are fairly new to the branch/trunk release maintenance game and want to get some input and provide some color about which patches should go where, especially in gray areas like this. JDH On Tue, Dec 16, 2008 at 6:08 PM, Michiel de Hoon mjldeh...@yahoo.com wrote: Dear all, I have now implemented the draw_path_collection, draw_quad_mesh, and draw_markers methods in the Mac OS X native backend (see patch 2179017 at http://sourceforge.net/tracker/?func=detailatid=560722aid=2179017group_id=80706). Some timings are below. In terms of raw drawing speed, the native backend can be either faster or slower than agg. On the other hand, the native backend can be considerably faster if the agg backend uses many calls to draw(); the native backend can avoid these superfluous because it has complete control over the event loop (see the third example below). # Timings in seconds # n Mac OS X TkAgg # 2 2 6 # 3 3 23 # 4 5 66 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
Hi Michiel, This looks great -- in particular I am intrigued by the final timing results which show your backend 12 times faster than tkagg. I am not sure where this speedup is coming from -- do you have some ideas? Because you are creating lots-o-subplots in that example, there is a lot of overhead at the python layer (many axes, many ticks, etc) so I don't see how a faster backend could generate such a significant improvement. What kind of timings do you see if you issue a plot rather than bar call in that example? One thing about bar in particular is that we draw lots of separate rectangles, each with thie own gc, and it has been on my wishlist for some time to do this as a collection. If you are handling gc creation, etc, in C, that may account for a big part of the difference. Since the new macosx backend was released in 0.98.5, I also need to decide whether this patch belongs on the branch, and hence will get pushed out as early as today in a bugfix release when some changes JJ and Michael are working on are ready, or the trunk, in which case it could be months. In favor of the trunk: this is more of a feature enhancement than a bugfix, and patches to the branch should be bugfixes with an eye to stability of the released code, though a good argument could be made that this is a bugfix. In favor of the branch: it is brand new code advertised as beta in 0.98.5 and so it is unlikely that anyone is using it seriously yet, and since it is beta, we should get as much of it out there ASAP so folks can test and pound on it. I'm in favor of branch, but I wanted to bring this up here since we are fairly new to the branch/trunk release maintenance game and want to get some input and provide some color about which patches should go where, especially in gray areas like this. JDH On Tue, Dec 16, 2008 at 6:08 PM, Michiel de Hoon mjldeh...@yahoo.com wrote: Dear all, I have now implemented the draw_path_collection, draw_quad_mesh, and draw_markers methods in the Mac OS X native backend (see patch 2179017 at http://sourceforge.net/tracker/?func=detailatid=560722aid=2179017group_id=80706). Some timings are below. In terms of raw drawing speed, the native backend can be either faster or slower than agg. On the other hand, the native backend can be considerably faster if the agg backend uses many calls to draw(); the native backend can avoid these superfluous because it has complete control over the event loop (see the third example below). # Timings in seconds # n Mac OS X TkAgg # 2 2 6 # 3 3 23 # 4 5 66 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
John Hunter wrote: Hi Michiel, This looks great -- in particular I am intrigued by the final timing results which show your backend 12 times faster than tkagg. I am not sure where this speedup is coming from -- do you have some ideas? Because you are creating lots-o-subplots in that example, there is a lot of overhead at the python layer (many axes, many ticks, etc) so I don't see how a faster backend could generate such a significant improvement. What kind of timings do you see if you issue a plot rather than bar call in that example? One thing about bar in particular is that we draw lots of separate rectangles, each with thie own gc, and it has been on my wishlist for some time to do this as a collection. If you are handling gc creation, etc, in C, that may account for a big part of the difference. Since the new macosx backend was released in 0.98.5, I also need to decide whether this patch belongs on the branch, and hence will get pushed out as early as today in a bugfix release when some changes JJ and Michael are working on are ready, or the trunk, in which case it could be months. In favor of the trunk: this is more of a feature enhancement than a bugfix, and patches to the branch should be bugfixes with an eye to stability of the released code, though a good argument could be made that this is a bugfix. In favor of the branch: it is brand new code advertised as beta in 0.98.5 and so it is unlikely that anyone is using it seriously yet, and since it is beta, we should get as much of it out there ASAP so folks can test and pound on it. I'm in favor of branch, but I wanted to bring this up here since we are fairly new to the branch/trunk release maintenance game and want to get some input and provide some color about which patches should go where, especially in gray areas like this. I'm +1 on going ahead and putting this on the branch, for the reasons you mentioned. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
Dear all, I have now implemented the draw_path_collection, draw_quad_mesh, and draw_markers methods in the Mac OS X native backend (see patch 2179017 at http://sourceforge.net/tracker/?func=detailatid=560722aid=2179017group_id=80706). Some timings are below. In terms of raw drawing speed, the native backend can be either faster or slower than agg. On the other hand, the native backend can be considerably faster if the agg backend uses many calls to draw(); the native backend can avoid these superfluous because it has complete control over the event loop (see the third example below). Best, --Michiel. # Scatter plot n = 1e6 import matplotlib.pyplot as plt f=plt.figure() import numpy as np x=np.arange(n) y=np.sin(x) ax=f.add_subplot(111) plt.scatter(x,y,c=x**2.0) # Time in seconds # n100,0001,000,000 2,000,0003,000,000 # MacOSX645 92 140 # WxAgg 756 112 172 # TkAgg 956 113 172 # GtkAgg755 111 173 # Quad mesh import numpy as np from matplotlib.pyplot import figure, show, savefig from matplotlib import cm, colors from numpy import ma n = 1000 x = np.cos(np.linspace(-1.5,1.5,n)) y = np.linspace(-1.5,1.5,n*2) X,Y = np.meshgrid(x,y); Qx = np.sin(Y**2) - np.cos(X) Qz = np.sin(Y) + np.sin(X) Qx = (Qx + 1.1) Z = np.sqrt(X**2 + Y**3)/5; Z = (Z - Z.min()) / (Z.max() - Z.min()) # The color array can include masked values: Zm = ma.masked_where(np.fabs(Qz) 0.5*np.amax(Qz), Z) fig = figure() ax = fig.add_subplot(111) ax.set_axis_bgcolor(#bdb76b) ax.pcolormesh(Qx,Qz,Z) show() # Timings in seconds # nMac OS X TkAgg # 500 6 6 # 1000 23 7 # 2000138 40 # Subplots from pylab import * figure() x=np.arange(20) y=1+x**2 n = 4 for i in range(n*n): subplot(n,n,i+1) bar(x,y,log=True) xlim(-5,25) ylim(1,1e4) # Timings in seconds # n Mac OS X TkAgg # 2 2 6 # 3 3 23 # 4 5 66 --- On Tue, 10/28/08, Michiel de Hoon mjldeh...@yahoo.com wrote: --- On Tue, 10/28/08, John Hunter jdh2...@gmail.com wrote: I haven't had a chance to look at the code yet, but I suspect he hasn't implemented the path collection draw method. If it's not implemented, we fall back on drawing each path separately, which is a lot slower. scatter ultimately triggers a call to Renderer.draw_path_collection which has a default implementation and a specialization in backend_agg. Good point. Indeed I was not aware of the draw_path_collection method and I have not implemented it. I will implement this method and report back with the timings for Eric's example. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
Michiel de Hoon wrote: --- On Tue, 10/28/08, Christopher Barker [EMAIL PROTECTED] wrote: I'm still curious where all this speed comes from. At this point, most of it is coming from having complete control over the event loop, which allows to avoid superfluous calls to draw(). well, what would be really nice is if we could figure out how to get rid of some of this superfluous calls to draw(0 in all the back-ends! I have noticed a bunch of extras in wxAgg, but had a hard time untangling it all. Also, OS-X does double buffer itself, so there may be extra work being done there is other back-ends -- essentially triple buffering. oh well. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
Nice work ... and an ambitious effort.
I've gotten it running, and am a bit perplexed by some of the
performance I'm seeing. Specifically, the following bit takes well
over twice as long to run as does WxAgg. Does this align with others'
testing?
The only difference I detect is that the Mac backend puts up a window
on the call to plt.figure, while WxAgg waits until the call to show().
Thanks,
Eric
# for testing macosx backend only
import matplotlib
matplotlib.use('macosx')
import matplotlib.pyplot as plt
f=plt.figure()
import numpy as np
x=np.arange(1e4)
y=np.sin(x)
ax=f.add_subplot(111)
sc=ax.scatter(x,y,c=x**2.0)
plt.show()
On Tue, Oct 28, 2008 at 12:13 PM, Christopher Barker
[EMAIL PROTECTED] wrote:
Michiel de Hoon wrote:
I wrote a backend for matplotlib on Mac OS X. This is a native
backend for Mac OS X
very nice!
4) One drawback compared to the existing cocoa-agg backend is that
the latter allows easy integration of matplotlib into a larger cocoa
application, whereas my backend only cares about matplotlib.
well, as far as many of us are concerned, matplotlib IS an embeddable
plotting package. I suppose you could say that your backend only cares
about pylab.
Is there any possibility to embed it in another app? I know that wx, for
instance, can pass a Window handle to other libs, so that you can have
that window managed and drawn by other code, while wx handles the rest
of the app -- would this kind of thing be possible with your code with
wx, and Cocoa, and QT, and ? I imagine GTK would be off the table as it
is using X11, though I suppose if you are using Apple's X11, it could
even be possible there.
Whereas matplotlib has a vastly superior range of high-level plotting
capabilities, pygist excelled at sheer speed. This was achieved by
having three backends (Windows, Mac OS X, X11) written in C for
optimal performance,
I'm still curious where all this speed comes from. MPL already uses Agg
for a lot, and it's generally reported to be as fast as many native
drawing APIs (though maybe not quartz?)
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[EMAIL PROTECTED]
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
On Tue, Oct 28, 2008 at 12:24 PM, Eric Bruning [EMAIL PROTECTED] wrote: Nice work ... and an ambitious effort. I've gotten it running, and am a bit perplexed by some of the performance I'm seeing. Specifically, the following bit takes well over twice as long to run as does WxAgg. Does this align with others' testing? I haven't had a chance to look at the code yet, but I suspect he hasn't implemented the path collection draw method. If it's not implemented, we fall back on drawing each path separately, which is a lot slower. scatter ultimately triggers a call to Renderer.draw_path_collection which has a default implementation and a specialization in backend_agg. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
--- On Tue, 10/28/08, Christopher Barker [EMAIL PROTECTED] wrote: 4) One drawback compared to the existing cocoa-agg backend is that the latter allows easy integration of matplotlib into a larger cocoa application, whereas my backend only cares about matplotlib. ... Is there any possibility to embed it in another app? I know that wx, for instance, can pass a Window handle to other libs, so that you can have that window managed and drawn by other code, while wx handles the rest of the app -- would this kind of thing be possible with your code with wx, and Cocoa, and QT, and ? That is a good idea. I'll check whether it is possible. Basically, if the embedding app can manage a window by passing it the window handle then it should be possible. I'm still curious where all this speed comes from. MPL already uses Agg for a lot, and it's generally reported to be as fast as many native drawing APIs (though maybe not quartz?) At this point, most of it is coming from having complete control over the event loop, which allows to avoid superfluous calls to draw(). Best, --Michiel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
--- On Tue, 10/28/08, John Hunter [EMAIL PROTECTED] wrote: I haven't had a chance to look at the code yet, but I suspect he hasn't implemented the path collection draw method. If it's not implemented, we fall back on drawing each path separately, which is a lot slower. scatter ultimately triggers a call to Renderer.draw_path_collection which has a default implementation and a specialization in backend_agg. Good point. Indeed I was not aware of the draw_path_collection method and I have not implemented it. I will implement this method and report back with the timings for Eric's example. Thanks! --Michiel. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
