On 7/19/07, Christopher Barker <[EMAIL PROTECTED]> wrote: > > This is potentially a major win, because we currently > > move the data around on every draw. > > Is it that expensive to push data around? In any case, it does sound > cleaner and more efficient not to.
It can be very expensive. Imagine you are smoothly panning or zooming a line object with 100,000 x,y points. All you are really doing is changing the affine. Although we've done some things to help this case, in matplotlib we still have to create a new path object every time in the agg backend, and then transform it. It's much cheaper just to push the affine to the backend in this case. So interaction with large data sets should get better. > > Do we want to use 3x3 or 4x4 to leave the door open for 3D developers? > > 4X4 -- is there much cost? The potential cost is not in the 3x3 vs 4x4, but in the extra row of junk data you would store in the data matrix, which is N extra values for plotting N points . The matrix multiplication would be 3x3 * 3xN vs 4x4 * 4xN , so there would be a cost in memory and performance. > > This approach requires the backends to be smarter, but they have to > > handle fewer entities. > > How many back-ends does the future hold? It seems if the GUI toolkits > all use *Agg, then that's only one render for all of them. Then we need: > > SVG > PDF > PS > Cairo would be nice, as it gives us almost all of them at once, but I > guess licensing keeps that a non-starter. Oh well. Not at all, we want to fully support Cairo. We just want to have some fully BSD compliant backends as well. agg 2.4 will remain BSD and I don't have too much of a problem relying on it. We are not alone in needing a BSD agg. I think the 4 you mentioned plus *Agg are the ones we should target. The goal is to get all the GUIs to work with a python buffer object or a numpy pixel buffer array -- if Agg and Cairo can provide the same buffer or numpy format, then we would automagically get *Agg and *Cairo across the GUIs. JDH ------------------------------------------------------------------------- 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
