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. Cheers, f ------------------------------------------------------------------------- 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
