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 <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
