On Jan 4, 2008 8:19 PM, Fernando Perez <[EMAIL PROTECTED]> wrote: > On Jan 4, 2008 11:55 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > > > > * Agg (this could be optional) > > > > > > On the transforms branch, Agg is used for bezier curve realisation, > > > whether the Agg renderer is being used or not. This is used for things > > > like hit-testing and range-setting of path collections etc. This was > > > not fast enough in my earlier numpy-based implementation, since to take > > > advantage of numpy, you generally have to allocate lots of memory to > > > store the results in. In this particular case, each value can be > > > immediately thrown away, so all that extra work was unnecessary. > > > > So it's needed for path collections - what is that? When I want to do > > regular plots, > > like plotting some set of points, is that needed too? If not, it > > should be optional imho. > > It's probably worth mentioning that one of the reasons John chose Agg > is because of image *quality* concerns. If I'm not mistaken (John and > A. Straw will correct me as needed), the OpenGL anti-aliasing quality > is positively horrible when you compare it to the quality of Agg. > Keep in mind that OpenGL is typically focused on keeping high > frame-rates for moving images, so pixel-perfect antialiasing is much > less of a concern for them, since your eye is a lot less likely to > notice such fine details (as long as there is *some* antialiasing). > For a static image, you tend to be a lot pickier, and Agg goes to > great lengths to ensure the best possible antialiasing quality. This > is part of the reason why normal television, at abysmally low > resolutions is still acceptable for viewing, while nobody would > consider a 400-line-image an acceptable photograph for most uses. You > 'stare' at the moving image only for 1/30 s or so, while you look at > the static one for much longer. > > Just look at some of their examples to get an idea of what I'm talking about: > > http://www.antigrain.com/screenshots/index.html > > I've never seen any opengl-based antialiasing be of that quality. But > there may be ways of achieving the same thing in OpenGL, I don't know > (and to do so efficiently and portably, without requiring specific > video cards). > > The other issue I recall is that the quality of openGL antialiasing is > highly dependent on the video card and/or driver. While that may be > OK for gamers, it's completely unacceptable IMO for scientific > publication. > > > > > Compiling really sucks. > > Keep in mind that while python+cleverness can get you a lot of speed, > there are operations that are *inescapably* slow in python's fully > dynamic model today (without JIT-type tricks a la psyco that avoid > dynamic dispatch in loops). Running a tight loop over a million > elements of anything to do some repetitive operation will incur in > Python's runtime check costs on every pass of the loop. In a plotting > library, this type of computation is very frequent, and while some of > it can be rolled into numpy-type array operations, that's not always > possible. There's simply no way out (today) from compiled code for > certain things in python, I'm afraid. Keep in mind that there are > still people who regularly complain about MPL being *too slow* for > their purposes, which involve interactive data exploration of enormous > datasets. I'm sure that loss of speed would not be considered a > desirable feature for a new MPL release by many :) > > I'm certainly hoping you guys can find some mechanism to join forces > on this front, which I would absolutely love to see. But I just want > to provide a bit of context as to why MPL uses extensions like Agg and > relies on compiled code, which is I think a fairly critical need of > the project. > > Having said all this, I'd be thrilled to be proven 100% wrong in all > of the above, and to see a pure-python MPL that is as fast as today's > and maintains the image quality we have today. > > One approach that has been thrown around in the past was to have an > opengl based render while working interactively, that would force a > re-render of the same entire scene via Agg for image saving. I don't > know enough about the MPL internals to say how feasible this would be.
Hi Fernando! what you said are valid points for matplotlib using Agg as a backend. And as I said, the default matplotlib installation should include it, no doubt about that. On the other hand, I (and I think many other users) only need the super quality only when saving the final plot. Of course, if it's worth the pain, I can install the agg backend and have the quality all the time, but many users will sacrifice the quality, if they can get at least some plot. If it was just me, I use Debian, so for me using any C compiled code is zero pain. But, the majority of users of sympy, are probably windows users. (At least there are more downloads of the windows installer, than the mulitplatform tarball). And I am not sure compiling anything on windows is a pleasant experience (honestly I think forcing a user of sympy compiling something on windows is a show stopper). Ondrej ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
