I was just wondering what the status of the CocoaAgg backend is since
there is not much info available.
Can it be used interactively w/ipython?
Can it be used to embed mpl in a cocoa app and take advantage of all
the xcode/interface builder stuff in OS X?
Thanks-
-stephen
I don't know for a fact, but the answer is probalby no. Each GUI
backend requires an explicit implementation in ipython, since they all
have their own threading/callback/timer quirks (even qt3 and qt4 are
different). Thus far, we don't have one for Cocoa. It may 'just
work', but I don't know that, so if you find that it doesn't, and
decide to dig in to implement the support, by all means send it our
way! The file to look at for inspiration is:
http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/IPython/Shell.py
Cheers,
f
On Dec 5, 2007 8:37 AM, Stephen Uhlhorn <stephenlists@...287...> wrote:
I was just wondering what the status of the CocoaAgg backend is since
there is not much info available.Can it be used interactively w/ipython?
Stephen,
The CocoaAgg backend is not supported in IPython. You can use it in the non-interactive form (i.e. with a pylab.show() but you will have to close the window in order to return control to the IPython shell). It is possible to embed an MPL plot in a Cocoa application using the same trick as the CocoaAgg backend (rendering the plot using the Agg backend and then turning the rasterized bitmap into and NSBitmapImageRep and then displaying it in an NSImageView). I've posted previously about a py2app plugin which does just that and has an IB palette, but I haven't had time to update the IB palette to use the IB 3 plugin API yet. It uses Cocoa Bindings to provide data to the plot. I'm happy to send it to you as is, or you can wait until it's IB 3 ready.
We (at my work) are just starting to think about writing a more direct Quartz backend for mpl. A native backend would let a matplotlib view participate in newer Cocoa technologies, such as resolution independence and CoreAnimation (it's possible with the current backend method, but not quite as flexible). This will make embedding easier, but will not solve the IPython issues. For now, one of the other backends, such as WXAgg or TkAgg is probably the better bet on OS X.
barry
On Dec 5, 2007, at 7:37 AM, Stephen Uhlhorn wrote:
I was just wondering what the status of the CocoaAgg backend is since
there is not much info available.Can it be used interactively w/ipython?
Can it be used to embed mpl in a cocoa app and take advantage of all
the xcode/interface builder stuff in OS X?Thanks-
-stephen-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@...813...
Though we'd love to support it, were a few patches to land our way 
Cheers,
f
On Dec 5, 2007 11:55 AM, Barry Wark <barrywark@...287...> wrote:
Stephen,
The CocoaAgg backend is not supported in IPython.
Barry Wark wrote:
We (at my work) are just starting to think about writing a more direct Quartz backend for mpl. A native backend would let a matplotlib view participate in newer Cocoa technologies, such as resolution independence and CoreAnimation (it's possible with the current backend method, but not quite as flexible).
I'm curious what Cocoa and CoreAnimation might enable...
If you are looking into writing a Quartz rendering backend, you may want to start with the matplotlib transforms branch (which should become the trunk shortly, once the 0.91 release bugs get shaken out.) The number of methods that a backend writer must provide has been greatly reduced on that branch.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Thanks for the background Barry.
I was asking because I have a bit of image processing/analysis code
(numpy/mpl/pil) that I would like to build a GUI front-end for. As I
am a recent convert to the osx world, I thought it would be very slick
to be able to do this with the xcode/IB tools. Since this is not
high-priority work right now, I'll stick with wx for now. I will be
interested to see how your Quartz backend comes along.
Michael,
I'm sorry. I just realized I hadn't replied to you yet; sorry for the
delay. John also pointed us to the transforms branch and that's where
we'll start. Thanks! There's no real advantage to CoreAnimation per se
(except eye candy), but going "native" for rendering would allow mpl
to integrate more smoothly with the rest of the 2D and 3D (much of
Quartz, and CoreImage the 2D rendering and filtering systems in OS X
are actually rendered on the graphics card as OpenGL) rendering system
in OS X. Some advantages, off the top of my head are resolution
independence, ability to offload rendering and/or coordinate
transformation to the graphics card, ability to easily produce output
in any of the CoreImage supported formats, ability to incorporate
transparency and alpha blending within the view hierarchy, ability to
combine media (QuickTime, OpenGL, and Quartz) in layers (the real
purpose of the CoreAnimation engine), ability to piggy back on
improvements in Apple's rendering engine (things like anti-aliasing
etc.), ColorSync support, and _maybe_ some speed improvements by
taking a layer or two out of the rendering process. All of these are
just speculation, at this time... we're just getting started but will
share our results as soon as they're ready.
barry
On 12/5/07, Michael Droettboom <mdroe@...86...> wrote:
Barry Wark wrote:
> We (at my work) are just starting to think about writing a more direct
> Quartz backend for mpl. A native backend would let a matplotlib view
> participate in newer Cocoa technologies, such as resolution
> independence and CoreAnimation (it's possible with the current backend
> method, but not quite as flexible).I'm curious what Cocoa and CoreAnimation might enable...
If you are looking into writing a Quartz rendering backend, you may want
to start with the matplotlib transforms branch (which should become the
trunk shortly, once the 0.91 release bugs get shaken out.) The number
of methods that a backend writer must provide has been greatly reduced
on that branch.Cheers,
Mike--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
All this sounds great. There has been some (off-list) discussion recently about making it easier to support third-party backends (i.e. backends that are maintained separately from the rest of the matplotlib tree). This Quartz backend may be a good test candidate for that (though I wouldn't worry about the details of that until some progress is made on making that possible). It seems like a natural fit for something that lives "a bit outside" since it is platform-specific.
Your list of advantages sound interesting. It will be great to see such things in action.
One minor comment --->
> ability to offload rendering and/or coordinate
> transformation to the graphics card
One of the desired goals of the transforms branch was to offload coordinate transformations to external renderers, for example, for PDF to offload it to Acrobat Reader via the PDF file. As it turns out, most of these systems (at least PDF, PS, SVG) all want to transform the stroke width using the same transform as the vertices of the object itself. So if you zoom in on the data, the line width becomes enormous. As it turned out, we weren't really able to take advantage of that, and end up transforming most things within matplotlib itself anyway (in a C extension).
But coordinate transformation is not a significant part of the runtime of the current software-only approaches anyway.
> ability to easily produce output
> in any of the CoreImage supported formats,
As an alternative, you may want to look at how the GtkAgg backend outputs to any of GtkPixbuf's supported formats, while using Agg as the renderer. Something analogous is likely possible with Quartz.
Personally, I'm curious to see how Quartz backend performs at producing PDF output, particularly with respect to fonts. That was a difficult thing to get right (and it still has room for improvement) in mpl's own PDF backend.
Cheers,
Mike
Barry Wark wrote:
Michael,
I'm sorry. I just realized I hadn't replied to you yet; sorry for the
delay. John also pointed us to the transforms branch and that's where
we'll start. Thanks! There's no real advantage to CoreAnimation per se
(except eye candy), but going "native" for rendering would allow mpl
to integrate more smoothly with the rest of the 2D and 3D (much of
Quartz, and CoreImage the 2D rendering and filtering systems in OS X
are actually rendered on the graphics card as OpenGL) rendering system
in OS X. Some advantages, off the top of my head are resolution
independence, ability to offload rendering and/or coordinate
transformation to the graphics card, ability to easily produce output
in any of the CoreImage supported formats, ability to incorporate
transparency and alpha blending within the view hierarchy, ability to
combine media (QuickTime, OpenGL, and Quartz) in layers (the real
purpose of the CoreAnimation engine), ability to piggy back on
improvements in Apple's rendering engine (things like anti-aliasing
etc.), ColorSync support, and _maybe_ some speed improvements by
taking a layer or two out of the rendering process. All of these are
just speculation, at this time... we're just getting started but will
share our results as soon as they're ready.barry
On 12/5/07, Michael Droettboom <mdroe@...86...> wrote:
Barry Wark wrote:
We (at my work) are just starting to think about writing a more direct
Quartz backend for mpl. A native backend would let a matplotlib view
participate in newer Cocoa technologies, such as resolution
independence and CoreAnimation (it's possible with the current backend
method, but not quite as flexible).I'm curious what Cocoa and CoreAnimation might enable...
If you are looking into writing a Quartz rendering backend, you may want
to start with the matplotlib transforms branch (which should become the
trunk shortly, once the 0.91 release bugs get shaken out.) The number
of methods that a backend writer must provide has been greatly reduced
on that branch.Cheers,
Mike--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
sorry to be a wet blanket, but...
Barry Wark wrote:
going "native" for rendering would allow mpl
to integrate more smoothly with the rest of the 2D and 3D
MPL is really only a 2D system -- there's been talk of the next generation version building 3D in, but we're really not there yet.
> ability to offload rendering and/or coordinate
transformation to the graphics card,
With the multi-backend paradigm, it's really hard to truly take advantage of this kind of thing -- optimum performance on any given platform is just not going to happen.
ability to easily produce output
in any of the CoreImage supported formats,
That's nice, but again, a bit out of sync with the cross platform nature of MPL.
ability to incorporate
transparency and alpha blending within the view hierarchy, ability to
combine media (QuickTime, OpenGL, and Quartz) in layers (the real
purpose of the CoreAnimation engine),
again -- very platform specific.
In short, CoreGraphics is the obvious choice for a Mac-only tools, but the advantages are greatly reduced for a platform and back-end independent tool like MPL. Which isn't to say that the Cocoa back-end isn't a good idea -- but the primary reason for it that I see is to be able to integrate with PyObjC apps.
Really, Agg (or Cairo, if we didn't have those pesky licensing issues) is a great way to go for a tool like MPL. It rally keeps things platform independent.
If MPL does go 3D in the future, then OpenGL is probably the way to go too -- it's more or less the same everywhere.
-Chris
--
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.Barker@...259...