On Jan 4, 2008 8:44 PM, Darren Dale <[EMAIL PROTECTED]> wrote: > > 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?
Right, maybe what I am trying to achieve is not really worthy. My idea is to have something integrated inside sympy, pure pythonic. I don't really want to depend on anything else. Because for everything else, there is Sage (full featured CAS system, with all the programs). SymPy is just for doing symbolic manipulation in python. 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
