matplotlib-devel Mailing List for matplotlib

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> The SVG backend is also useful for debugging because it
    Steve> gives you a text list of everything the frontend does. For
    Steve> example I can look at the output of './simple_plot.py
    Steve> -dSVG' and see that the frontend seems to have a bug where
    Steve> its drawing every tickline twice. I had a look at axis.py
    Steve> but could not work out what was going on.

Just found and fixed this one.  The problem was in axis.py.  All of
the thick creation functions were like

    def _get_tick2line(self, loc):
        'Get the default line2D instance'
        # x in axes coords, y in data coords
        l = Line2D( (1,1), (0,0), color='k',
                    antialiased=False,
                    marker = TICKLEFT,
                    linestyle = 'None',
                    markersize=self._size,
                    )


and later these positions were updated like

        self.tick2line.set_ydata((y,y))

These should all be length one lists


        l = Line2D( (1,), (0,), color='k',
                    antialiased=False,
                    marker = TICKLEFT,
                    linestyle = 'None',
                    markersize=self._size,
                    )


        self.tick2line.set_ydata((y,))

Fixed in CVS

JDH

Currently, when writing a SVG, all raster images produced by imshow are
scaled to a fixed, low resolution. (72dpi?)

The least I would expect is the 'dpi=' option of savefig to be used for
writing PNGs in the SVG renderer.

Even better would be to switch off rescaling completely for any vector
output (EPS and SVG). This would allow optimal quality in post-processing.

I even believe that rescaling to a uniform resolution should be an
option, not the default.

Has anybody else spent thought on this?

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John> I think we have a problem in GTK.  In the script below, if
    John> you add a button or some other widget above the figure
    John> canvas, only a part of the canvas is updated in the
    John> motion_notify_event update.  The distance from the top of
    John> the figure canvas to the part that is not updated is equal
    John> to the height of the widget packed above the canvas.  You
    John> can observe this by resizing the window to make it taller or
    John> shorter and noting the vertical extent where the horizontal
    John> line disappears.

I think the answer is

    def draw(self):
        # synchronous window redraw (like GTK+ 1.2 used to do)
        # Note: this does not follow the usual way that GTK redraws,
        # which is asynchronous redraw using calls to gtk_widget_queue_draw(),
        # which triggers an expose-event
        
        # GTK+ 2.x style draw()
        #self._need_redraw = True
        #self.queue_draw()

        # synchronous draw (needed for animation)
        x, y, w, h = self.allocation
        #print x, y, w, h
        self._pixmap_prepare (w, h)
        self._render_figure(self._pixmap, w, h)
        self._need_redraw = False
        self.window.draw_drawable (self.style.fg_gc[self.state],
                                   self._pixmap, 0, 0, 0, 0, w, h)
                                                 ^^^^^^^^^^

I think we have a problem in GTK.  In the script below, if you add a
button or some other widget above the figure canvas, only a part of
the canvas is updated in the motion_notify_event update.  The distance
from the top of the figure canvas to the part that is not updated is
equal to the height of the widget packed above the canvas.  You can
observe this by resizing the window to make it taller or shorter and
noting the vertical extent where the horizontal line disappears.

In the example below, when you move your mouse over the canvas, the
sine wave update will affect only part of the sine, and the horizontal
line will only update below this mystery boundary.

If you comment out the line that packs in the button, the script will
behave correctly.

Perhaps we are screwing up the pixmap management.

I initially thought this was a problem with gtkagg, but on further
examination I found it applies to plain-vanilla-gtk as well as gtkagg.

Any ideas?

#!/usr/bin/env python
"""
show how to add a matplotlib FigureCanvasGTK or FigureCanvasGTKAgg widget and
a toolbar to a gtk.Window
"""
from matplotlib.figure import Figure
from matplotlib.numerix import arange, sin, pi

#from matplotlib.backends.backend_gtkagg import FigureCanvasGTKAgg as FigureCanvas
from matplotlib.backends.backend_gtk import FigureCanvasGTK as FigureCanvas

import gtk

win = gtk.Window()
win.connect("destroy", lambda x: gtk.main_quit())
win.set_default_size(400,600)
win.set_title("Embedding in GTK")

vbox = gtk.VBox()
win.add(vbox)

fig = Figure(dpi=100)
ax = fig.add_subplot(111, autoscale_on=False)
t = arange(0.0,3.0,0.01)
s = sin(2*pi*t)

sline, = ax.plot(t,s)
ax.set_ylim((-1,1))

line, = ax.plot([0,3], [0,0], color='red', linewidth=2)

if 1: # if button is visible bug is exposed
    button = gtk.Button('Hi mom')
    button.show()
    vbox.pack_start(button, True, True)


canvas = FigureCanvas(fig)  # a gtk.DrawingArea
canvas.set_size_request(400,400)
vbox.pack_start(canvas, True, True)



def update(event):
    if not event.inaxes: return 
    print event.ydata
    
    sline.set_ydata(2*sin(2*pi*t))
    line.set_ydata((event.ydata, event.ydata))
    canvas.draw()
    return False

canvas.mpl_connect('motion_notify_event', update)

win.show_all()
gtk.main()