On Friday 04 January 2008 02:36:06 pm Ondrej Certik wrote: > 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).
Why would your users have to compile anything on windows? Matplotlib's windows users just run the installer, the compilation has already been done. Am I missing something? Darren ------------------------------------------------------------------------- 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
