matplotlib-devel Mailing List for matplotlib

Michael Droettboom wrote:
> You're right: my bad. Should be fixed in r3461.
> 
I meant to type r3484.
> Cheers,
> Mike
>
> Eric Firing wrote:
> 
>> Mike,
>>
>> When I try to save a file as postscript using the FileChooserDialog 
>> with GtkAgg, I get:
>>
>> efiring@manini:~/programs/py/mpl/matplotlib_units/examples$ python 
>> quadmesh_demo.py
>> Traceback (most recent call last):
>> File 
>> "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
>> line 696, in save_figure
>> fname = self.fileselect.get_filename_from_user()
>> File 
>> "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
>> line 1095, in get_filename_from_user
>> menu_ext = IMAGE_FORMAT[self.cbox.get_active()]
>> AttributeError: 'FileChooserDialog' object has no attribute 'cbox'
>>
>> I haven't checked, but I suspect this may be a bug introduced during 
>> your recent changes.
>>
>> Eric
>> 
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> 

You're right: my bad. Should be fixed in r3461.
Cheers,
Mike
Eric Firing wrote:
> Mike,
>
> When I try to save a file as postscript using the FileChooserDialog 
> with GtkAgg, I get:
>
> efiring@manini:~/programs/py/mpl/matplotlib_units/examples$ python 
> quadmesh_demo.py
> Traceback (most recent call last):
> File 
> "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
> line 696, in save_figure
> fname = self.fileselect.get_filename_from_user()
> File 
> "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
> line 1095, in get_filename_from_user
> menu_ext = IMAGE_FORMAT[self.cbox.get_active()]
> AttributeError: 'FileChooserDialog' object has no attribute 'cbox'
>
> I haven't checked, but I suspect this may be a bug introduced during 
> your recent changes.
>
> Eric

Hi,
First, I noticed a bug in the version I sent before. I've attached a new
version in patch form, to be applied from the base directory of a normal
0.90.1 installation with 'patch -p1 <patch'.
One artifact I can clearly see is there is partly due to skipping lines <
1 pixel in length. The original agg renderer did this too, so it is not
too different from before. My patch makes it worse, though. You can see it
with plot(rand(10000)) again, but zoom out on only the y axis until the
data is almost a straight line from right to left. You should see little
clumps appear as it gets close to a straight line.
Besides this I have not noticed anything. There may be problem cases I
have not thought of, of course. To see the kind of problem that might
occur, you can try changing the distance cutoff from 0.25 to something
huge like 25.0. There you will definitely notice errors.
About doing this for other image formats: I think it is OK for pixel-based
images, but probably not for SVG or vector-based images. I can imagine
someone writing to an SVG so that they can use another program to make a
pretty rendering of it, but if lines are missing this second program does
not have the full data to work with.
Allan
On Sat, July 7, 2007 10:15 pm, Eric Firing wrote:
> John,
>
>
> Have you considered Allan's version of _backend_agg.cpp (message date
> was 06/27)? I just tried it, and so far, I like it. I have not found any
> problems with the backend_driver.py test, and the improvement in speed
> that Allan notes with the "plot(rand(100000))" example is dramatic--the
> difference between unusable for panning and zooming with the original
> backend, and quite responsive and very usable with Allan's version.
>
> I have not tried to understand the algorithm or code.
>
>
> Allan,
>
>
> Can you suggest a simple test that graphically illustrates the "loss of
> accuracy", perhaps a worst case, so we can see whether this is an actual
> problem?
>
> I am also wondering whether your optimization technique, or some
> variation of it, could and should be applied in the generation of
> vector-based printer files: ps, pdf, svg. They can get excessively large
> and slow with very large datasets, and the ability to trim them with
> minimal loss of genuine information conveyed to the ultimate viewer of the
> plot would be very nice.
>
> Eric

Carl,
I've not been following the matplotlib mailing lists recently, but I
came across your blog and had a look at the cairo patches. It looks like
all the cairo patches are against some old version of matplotlib.
patch #2 enable clipping
I enabled clipping in Jan-2007.
patch #1 for 'snapping'
The patch did not reach the mailing list (?). But in a later mail you
mention that snapping smooth, curved user data is a really bad idea. So
the patch should probably not be applied.
patch #3 snap dash lengths, relies on patch #1.
I think this patch has the problems of patch #1 - if the dashes are
being used to draw axes or gridlines then snapping is OK. But if the
dashes are for user data then snapping is not necessarily what you want.
I think the real problem highlighted by patches #1 and #3 is that
matplotlib (the frontend) does not tell the backends when it is drawing
the plot axes and gridlines to enable the backends to switch on pixel
aligned drawing.
patch #4 for arcs
Looks good, applied it today.
Regards,
Steve.

On Fri, Jul 06, 2007 at 05:31:58PM -0400, Paul Kienzle wrote:
> On Fri, Jul 06, 2007 at 10:15:48AM -0500, John Hunter wrote:
> > On 7/6/07, Paul Kienzle <pki...@ni...> wrote:
> > > Instead I would like to start by splitting the current pick method
> > > into two parts:
> > > contains(event,picker) which returns truth value,details
> > > pick(event) which generates the current pick event
> > 
> > I don't really understand the contains part -- can you elaborate a little bit?
> > 
> > I would definitely be amenable to accepting patches that improve the
> > current API :-)
> 
> I have an initial patch against CVS available which implements
> contains() for most classes. Legend is too complex for simple hacks.
> I have a number of questions regarding details of implementation,
> in particular determining sizes of things on the plot.
> 
> The question now is what to do with it? I can post it to the patch
> tracker on sourceforge, but I'm hesitant to do so since it still
> has issues. Do you want it there or on the list?
I submitted the 'contains' patch to the patch tracker on sourceforge.
I've worked out most of the issues, including selecting lines instead
of just points. I still haven't addressed legend picking, and I don't
know how to handle line offsets. I'm also unhappy with relying on
a cached renderer for some of the size checks (e.g., text extents).
One solution is to send this along with the 'contains' test, though
that would mean changing the interface to pick. Any other suggestions?
In backend_bases.FigureCanvasBase.__init__ there is an "if False" 
statement. Turn it to True and all objects on every graph will be
highlighted as the mouse hovers over them and restored when it moves
away. I worked through many of the demos in the repository to check
that the various objects are recognized.
Sorry about the size of the patch --- I wanted to keep the system in a
working state so I had to do everything. Also I spent some time 
writing __str__ methods for a lot of the artists so that it was easier 
for me to debug. Let me know if you want these stripped and sent as 
a separate patch.
- Paul

Mike,
When I try to save a file as postscript using the FileChooserDialog with 
GtkAgg, I get:
efiring@manini:~/programs/py/mpl/matplotlib_units/examples$ python 
quadmesh_demo.py
Traceback (most recent call last):
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 696, in save_figure
 fname = self.fileselect.get_filename_from_user()
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 1095, in get_filename_from_user
 menu_ext = IMAGE_FORMAT[self.cbox.get_active()]
AttributeError: 'FileChooserDialog' object has no attribute 'cbox'
I haven't checked, but I suspect this may be a bug introduced during 
your recent changes.
Eric

John,
Have you considered Allan's version of _backend_agg.cpp (message date 
was 06/27)? I just tried it, and so far, I like it. I have not found 
any problems with the backend_driver.py test, and the improvement in 
speed that Allan notes with the "plot(rand(100000))" example is 
dramatic--the difference between unusable for panning and zooming with 
the original backend, and quite responsive and very usable with Allan's 
version.
I have not tried to understand the algorithm or code.
Allan,
Can you suggest a simple test that graphically illustrates the "loss of 
accuracy", perhaps a worst case, so we can see whether this is an actual 
problem?
I am also wondering whether your optimization technique, or some 
variation of it, could and should be applied in the generation of 
vector-based printer files: ps, pdf, svg. They can get excessively 
large and slow with very large datasets, and the ability to trim them 
with minimal loss of genuine information conveyed to the ultimate viewer 
of the plot would be very nice.
Eric
ah...@cs... wrote:
> Hi,
> 
> I've been plotting data with millions of datapoints, and it takes a long
> time for the plot to draw and to rescale with the mouse. I was playing
> around with the draw_lines function in the agg backend and sped it up a
> bit, maybe others will find it useful. I've attached my optimized version
> of _backend_agg.cpp. (just replace the old src/_backend_agg.cpp and
> recompile).
> 
> The main optimization is to combine sequential lines that are parallel
> into a single line to be drawn once. Try "plot(rand(100000),'-')" to see
> the change. Resizing and zooming should be faster than before.
> 
> This comes at the expense of accuracy since many lines are not drawn. I've
> tried to balance out accuracy vs speed to my liking. The main thing to
> tweak is a length threshold which I have hardcoded to 0.25. This is the
> squared length in pixels that we can move in the direction perpendicular
> to the set of parallel lines we are combining and still combine the lines.
> (so it can move 0.5 pixels to the side before a new line will be started).
> If you set it to 0, you should get the same plots as without my changes.
> 
> I also made it skip any lines that are outside of the drawing area.
> 
> Hopefully it's not buggy!
> 
> Allan