matplotlib-devel Mailing List for matplotlib (Page 3)

Hi,
I am having a problem with matplotlib. I am plotting two data points on a graph
and after setting up my locators (DayLocator), I am calling autoscale_view() on
the axis and the function ends up in the infinite loop. I am trying to come up
with with a short case that will trigger the problem at the moment but it's a
web process and isn't very easy to trace. The following is the function where
the infinite loop happens. I am having a bit of trouble tracing through it and
figuring out what exactly causes it to be in the inifinite loop.
Thanks,
Maria Khomenko
This is the functon (in /dateutils/rrule.py, class rrule)
def _iter(self):
 year, month, day, hour, minute, second, weekday, yearday, _ = \
 self._dtstart.timetuple()
 # Some local variables to speed things up a bit
 freq = self._freq
 interval = self._interval
 wkst = self._wkst
 until = self._until
 bymonth = self._bymonth
 byweekno = self._byweekno
 byyearday = self._byyearday
 byweekday = self._byweekday
 byeaster = self._byeaster
 bymonthday = self._bymonthday
 bynmonthday = self._bynmonthday
 bysetpos = self._bysetpos
 byhour = self._byhour
 byminute = self._byminute
 bysecond = self._bysecond
 ii = _iterinfo(self)
 ii.rebuild(year, month)
 getdayset = {YEARLY:ii.ydayset,
 MONTHLY:ii.mdayset,
 WEEKLY:ii.wdayset,
 DAILY:ii.ddayset,
 HOURLY:ii.ddayset,
 MINUTELY:ii.ddayset,
 SECONDLY:ii.ddayset}[freq]
 
 if freq < HOURLY:
 timeset = self._timeset
 else:
 gettimeset = {HOURLY:ii.htimeset,
 MINUTELY:ii.mtimeset,
 SECONDLY:ii.stimeset}[freq]
 if ((freq >= HOURLY and
 self._byhour and hour not in self._byhour) or
 (freq >= MINUTELY and
 self._byminute and minute not in self._byminute) or
 (freq >= SECONDLY and
 self._bysecond and minute not in self._bysecond)):
 timeset = ()
 else:
 timeset = gettimeset(hour, minute, second)
 total = 0
 count = self._count
 while True:
 # Get dayset with the right frequency
 dayset, start, end = getdayset(year, month, day)
 # Do the "hard" work ;-)
 filtered = False
 for i in dayset[start:end]:
 if ((bymonth and ii.mmask[i] not in bymonth) or
 (byweekno and not ii.wnomask[i]) or
 (byyearday and (i%ii.yearlen)+1 not in byyearday) or
 (byweekday and ii.wdaymask[i] not in byweekday) or
 (ii.nwdaymask and not ii.nwdaymask[i]) or
 (byeaster and not ii.eastermask[i]) or
 ((bymonthday or bynmonthday) and
 ii.mdaymask[i] not in bymonthday and
 ii.nmdaymask[i] not in bynmonthday)):
 dayset[i] = None
 filtered = True
 # Output results
 if bysetpos and timeset:
 poslist = []
 for pos in bysetpos:
 if pos < 0:
 daypos, timepos = divmod(pos, len(timeset))
 else:
 daypos, timepos = divmod(pos-1, len(timeset))
 try:
 i = [x for x in dayset[start:end]
 if x is not None][daypos]
 time = timeset[timepos]
 except IndexError:
 pass
 else:
 date = datetime.date.fromordinal(ii.yearordinal+i)
 res = datetime.datetime.combine(date, time)
 if res not in poslist:
 poslist.append(res)
 poslist.sort()
 for res in poslist:
 if until and res > until:
 self._len = total
 return
 elif res >= self._dtstart:
 total += 1
 yield res
 if count:
 count -= 1
 if not count:
 self._len = total
 return
 else:
 for i in dayset[start:end]:
 if i is not None:
 date = datetime.date.fromordinal(ii.yearordinal+i)
 for time in timeset:
 res = datetime.datetime.combine(date, time)
 if until and res > until:
 self._len = total
 return
 elif res >= self._dtstart:
 total += 1
 yield res
 if count:
 count -= 1
 if not count:
 self._len = total
 return
 # Handle frequency and interval
 fixday = False
 if freq == YEARLY:
 year += interval
 if year > datetime.MAXYEAR:
 self._len = total
 return
 ii.rebuild(year, month)
 elif freq == MONTHLY:
 month += interval
 if month > 12:
 div, mod = divmod(month, 12)
 month = mod
 year += div
 if month == 0:
 month = 12
 year -= 1
 if year > datetime.MAXYEAR:
 self._len = total
 return
 ii.rebuild(year, month)
 elif freq == WEEKLY:
 if wkst > weekday:
 day += -(weekday+1+(6-wkst))+self._interval*7
 else:
 day += -(weekday-wkst)+self._interval*7
 weekday = wkst
 fixday = True
 elif freq == DAILY:
 day += interval
 fixday = True
 elif freq == HOURLY:
 if filtered:
 # Jump to one iteration before next day
 hour += ((23-hour)//interval)*interval
 while True:
 hour += interval
 div, mod = divmod(hour, 24)
 if div:
 hour = mod
 day += div
 fixday = True
 if not byhour or hour in byhour:
 break
 timeset = gettimeset(hour, minute, second)
 elif freq == MINUTELY:
 if filtered:
 # Jump to one iteration before next day
 minute += ((1439-(hour*60+minute))//interval)*interval
 while True:
 minute += interval
 div, mod = divmod(minute, 60)
 if div:
 minute = mod
 hour += div
 div, mod = divmod(hour, 24)
 if div:
 hour = mod
 day += div
 fixday = True
 filtered = False
 if ((not byhour or hour in byhour) and
 (not byminute or minute in byminute)):
 break
 timeset = gettimeset(hour, minute, second)
 elif freq == SECONDLY:
 if filtered:
 # Jump to one iteration before next day
 second += (((86399-(hour*3600+minute*60+second))
 //interval)*interval)
 while True:
 second += self._interval
 div, mod = divmod(second, 60)
 if div:
 second = mod
 minute += div
 div, mod = divmod(minute, 60)
 if div:
 minute = mod
 hour += div
 div, mod = divmod(hour, 24)
 if div:
 hour = mod
 day += div
 fixday = True
 if ((not byhour or hour in byhour) and
 (not byminute or minute in byminute) and
 (not bysecond or second in bysecond)):
 break
 timeset = gettimeset(hour, minute, second)
 if fixday and day > 28:
 daysinmonth = calendar.monthrange(year, month)[1]
 if day > daysinmonth:
 while day > daysinmonth:
 day -= daysinmonth
 month += 1
 if month == 13:
 month = 1
 year += 1
 if year > datetime.MAXYEAR:
 self._len = total
 return
 daysinmonth = calendar.monthrange(year, month)[1]
 ii.rebuild(year, month)

	Alright, I think its ready to go. I can't say I am thrilled with the 
performance of the TkAgg compared to the GtkAgg. I get about 62fps compared to 
112fps for gtkagg. It is still a LOT faster.
	FYI, the current state of examples/animation_blit.py does nothing, and you 
print a fps for 200 frames when only 50 are actually drawn giving an 
unrealistically high fps measurement.
	Finally, could you please send me a windows-2.4 binary of current cvs. I have 
a project that I am wanting to use the blitting for the tkagg and I want to test 
on windows. I don't have a build environment for it. If it is too much 
trouble, it is not a big deal.
Thanks,
	Charlie
John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
> Charles> 	I am really close on having blit work for the tkagg.
> Charles> I committed my changes. There is one problem left I was
> Charles> hoping you could help on. I blit the axes in the right
> Charles> place, but it is blitting the upper-left of the whole
> Charles> figure. Running your test script below, this is easily
> Charles> seen. How do I pass in just the pixmap of the area of
> Charles> interest?
> 
> You are very close :-)
> 
> You need to follow the logic of the "destbuffer" in _gtkagg src. This
> will either use the who agg pixBuffer if bbox is None, or else copy
> out the proper region of the agg pixel buffer into destbuffer. There
> is a boolean "needfree" that keeps track of whether you need to free
> the memory. This is true when bbox!=None since we have to allocate a
> temporary buffer to copy the rectangle of the pixBuffer into.
> 
> You then pass destbuffer instead of pixBuffer off to the tk drawing
> routine.
> 
> Thanks!
> JDH
> 
> bool needfree = false;
> 
> agg::int8u *destbuffer = NULL;
> if (args[2].ptr() == Py_None) {
> //bbox is None; copy the entire image
> destbuffer = aggRenderer->pixBuffer;
> destwidth = srcwidth;
> destheight = srcheight;
> deststride = srcstride;
> }
> else {
> //bbox is not None; copy the image in the bbox
> 
> Bbox* clipbox = static_cast<Bbox*>(args[2].ptr());
> double l = clipbox->ll_api()->x_api()->val() ; 
> double b = clipbox->ll_api()->y_api()->val();
> double r = clipbox->ur_api()->x_api()->val() ; 
> double t = clipbox->ur_api()->y_api()->val() ;
> 
> //std::cout << b << " " 
> //		<< t << " ";
> 
> destx = (int)l;
> desty = srcheight-(int)t;
> destwidth = (int)(r-l);
> destheight = (int)(t-b);
> deststride = destwidth*4;
> 
> needfree = true;
> destbuffer = new agg::int8u[deststride*destheight]; 
> if (destbuffer ==NULL) {
> 	throw Py::MemoryError("_gtkagg could not allocate memory for destbuffer");
> }
> 
> agg::rendering_buffer destrbuf;
> destrbuf.attach(destbuffer, destwidth, destheight, deststride);
> pixfmt destpf(destrbuf);
> renderer_base destrb(destpf);
> //destrb.clear(agg::rgba(1, 0, 0));
> 
> //std::cout << "rect " << r << " " << srcheight << " " << b << " ";
> agg::rect_base<int> region(destx, desty, (int)r, srcheight-(int)b); 
> destrb.copy_from(*aggRenderer->renderingBuffer, &region, 
> 		 -destx, -desty);
> 
> 
> }
> 
> 
> gdk_draw_rgb_32_image(drawable, gc, destx, desty, 
> 			 destwidth, 
> 			 destheight, 
> 			 GDK_RGB_DITHER_NORMAL,
> 			 destbuffer,
> 			 deststride);
> 
> if (needfree) delete [] destbuffer;
> 
> Charles> - Charlie

>>>>> "Charles" == Charles Moad <cm...@in...> writes:
 Charles> 	I am really close on having blit work for the tkagg.
 Charles> I committed my changes. There is one problem left I was
 Charles> hoping you could help on. I blit the axes in the right
 Charles> place, but it is blitting the upper-left of the whole
 Charles> figure. Running your test script below, this is easily
 Charles> seen. How do I pass in just the pixmap of the area of
 Charles> interest?
You are very close :-)
You need to follow the logic of the "destbuffer" in _gtkagg src. This
will either use the who agg pixBuffer if bbox is None, or else copy
out the proper region of the agg pixel buffer into destbuffer. There
is a boolean "needfree" that keeps track of whether you need to free
the memory. This is true when bbox!=None since we have to allocate a
temporary buffer to copy the rectangle of the pixBuffer into.
You then pass destbuffer instead of pixBuffer off to the tk drawing
routine.
Thanks!
JDH
 bool needfree = false;
 agg::int8u *destbuffer = NULL;
 if (args[2].ptr() == Py_None) {
 //bbox is None; copy the entire image
 destbuffer = aggRenderer->pixBuffer;
 destwidth = srcwidth;
 destheight = srcheight;
 deststride = srcstride;
 }
 else {
 //bbox is not None; copy the image in the bbox
 
 Bbox* clipbox = static_cast<Bbox*>(args[2].ptr());
 double l = clipbox->ll_api()->x_api()->val() ; 
 double b = clipbox->ll_api()->y_api()->val();
 double r = clipbox->ur_api()->x_api()->val() ; 
 double t = clipbox->ur_api()->y_api()->val() ;
 
 //std::cout << b << " " 
 //		<< t << " ";
 destx = (int)l;
 desty = srcheight-(int)t;
 destwidth = (int)(r-l);
 destheight = (int)(t-b);
 deststride = destwidth*4;
 
 needfree = true;
 destbuffer = new agg::int8u[deststride*destheight]; 
 if (destbuffer ==NULL) {
	throw Py::MemoryError("_gtkagg could not allocate memory for destbuffer");
 }
 
 agg::rendering_buffer destrbuf;
 destrbuf.attach(destbuffer, destwidth, destheight, deststride);
 pixfmt destpf(destrbuf);
 renderer_base destrb(destpf);
 //destrb.clear(agg::rgba(1, 0, 0));
 
 //std::cout << "rect " << r << " " << srcheight << " " << b << " ";
 agg::rect_base<int> region(destx, desty, (int)r, srcheight-(int)b); 
 destrb.copy_from(*aggRenderer->renderingBuffer, &region, 
		 -destx, -desty);
 
 
 }
 gdk_draw_rgb_32_image(drawable, gc, destx, desty, 
			 destwidth, 
			 destheight, 
			 GDK_RGB_DITHER_NORMAL,
			 destbuffer,
			 deststride);
 
 if (needfree) delete [] destbuffer;
 Charles> - Charlie

	I am really close on having blit work for the tkagg. I committed my changes. 
There is one problem left I was hoping you could help on. I blit the axes in 
the right place, but it is blitting the upper-left of the whole figure. 
Running your test script below, this is easily seen. How do I pass in just the 
pixmap of the area of interest?
- Charlie
John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
> Charles> I added the blit method to the tkagg, but I don't know
> Charles> what needs to be done to take the bbox into account.
> Charles> Even as it stands I get 141 fps in animation_blit.py
> Charles> compared to gtk's 350 fps. Whoever is the tk expert, any
> Charles> clue on how to account for the bbox on blit updates?
> 
> Todd wrote this, but I can point you to the relevant section of code.
> 
> tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
> 
> calls backends.tkagg.blit
> 
> def blit(photoimage, aggimage, colormode=1):
> tk = photoimage.tk
> try:
> tk.call("PyAggImagePhoto", photoimage, id(aggimage), colormode)
> except Tk.TclError, v:
> try:
> try:
> _tkagg.tkinit(tk.interpaddr(), 1)
> except AttributeError:
> _tkagg.tkinit(id(tk), 0)
> tk.call("PyAggImagePhoto", photoimage, id(aggimage), colormode)
> except (ImportError, AttributeError, Tk.TclError):
> raise
> 
> and PyAggImagePhoto is the relevant function which is defined in
> src/_tkagg.cpp
> 
> static int
> PyAggImagePhoto(ClientData clientdata, Tcl_Interp* interp,
> int argc, char **argv)
> {
> Tk_PhotoHandle photo;
> Tk_PhotoImageBlock block;
> PyObject* aggo;
> //...snip....
> 
> 
> 
> block.width = aggRenderer->get_width();
> block.height = aggRenderer->get_height();
> //std::cout << "w,h: " << block.width << " " << block.height << std::endl;
> block.pitch = block.width * nval;
> block.pixelPtr = aggRenderer->pixBuffer;
> /* Clear current contents */
> Tk_PhotoBlank(photo);
> /* Copy opaque block to photo image, and leave the rest to TK */
> Tk_PhotoPutBlock(photo, &block, 0, 0, block.width, block.height);
> 
> I assume the 0, 0 are the x and y offsets and block.width,
> block.height are the sizes of the rect to be transferred. By
> following the example of src/_gtkagg.cpp, you should be able to
> substitute in the information from the bbox where appropriate.
> 
> BTW, I am getting 51 FPS with Tkagg using your blit. My test script
> is below:
> 
> import matplotlib
> matplotlib.use('TkAgg')
> import sys
> import gtk, gobject
> import pylab as p
> import matplotlib.numerix as nx
> import time
> 
> ax = p.subplot(111)
> canvas = ax.figure.canvas
> 
> 
> # create the initial line
> x = nx.arange(0,2*nx.pi,0.01)
> line, = p.plot(x, nx.sin(x), animated=True)
> 
> def run(*args):
> background = canvas.copy_from_bbox(ax.bbox)
> # for profiling
> tstart = time.time()
> 
> while 1:
> # restore the clean slate background
> canvas.restore_region(background)
> # update the data
> line.set_ydata(nx.sin(x+run.cnt/10.0)) 
> # just draw the animated artist
> ax.draw_artist(line)
> # just redraw the axes rectangle
> canvas.blit(ax.bbox) 
> 
> if run.cnt==200:
> # print the timing info and quit
> print 'FPS:' , 200/(time.time()-tstart)
> sys.exit()
> 
> run.cnt += 1
> run.cnt = 0 
> 
> 
> manager = p.get_current_fig_manager()
> manager.window.after(100, run)
> 
> p.show()
> 
> 
> 

On Fri, 2005年08月05日 at 20:28 -0700,
mat...@li... wrote:
> >>>>> "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)
> ^^^^^^^^^^
That looks correct.
I was confusing the event.area rectangle with the allocation rectangle.
For event.area x,y is relative to the widget and "x,y,x,y,w,h" works.
But self.allocation x,y is relative to the parent so you need
"0,0,0,0,w,h".
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

	Yeah, sorry I haven't had much time to work on it lately. The save 
button is pretty much a place holder for what I was going to add. My 
last headache was making multiple figures/windows work.
Thanks,
	Charlie
Jeff Whitaker wrote:
> 
> The Matplotlib.nib directory is missing in the 0.83.2 source tarball. 
> It needs to be installed in <sys.prefix>/share/matplotlib for the 
> CocoaAgg backend to work. I manually retrieved it from CVS and put it 
> there, and it seems to work - except for the 'Save Figure'
> button which doesn't seem to do anything yet.
> 
> -Jeff
> 

The Matplotlib.nib directory is missing in the 0.83.2 source tarball. 
It needs to be installed in <sys.prefix>/share/matplotlib for the 
CocoaAgg backend to work. I manually retrieved it from CVS and put it 
there, and it seems to work - except for the 'Save Figure'
button which doesn't seem to do anything yet.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449
325 Broadway Web : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

>>>>> "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()

>>>>> "Charles" == Charles Moad <cm...@in...> writes:
 Charles> I added the blit method to the tkagg, but I don't know
 Charles> what needs to be done to take the bbox into account.
 Charles> Even as it stands I get 141 fps in animation_blit.py
 Charles> compared to gtk's 350 fps. Whoever is the tk expert, any
 Charles> clue on how to account for the bbox on blit updates?
Todd wrote this, but I can point you to the relevant section of code.
 tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
calls backends.tkagg.blit
def blit(photoimage, aggimage, colormode=1):
 tk = photoimage.tk
 try:
 tk.call("PyAggImagePhoto", photoimage, id(aggimage), colormode)
 except Tk.TclError, v:
 try:
 try:
 _tkagg.tkinit(tk.interpaddr(), 1)
 except AttributeError:
 _tkagg.tkinit(id(tk), 0)
 tk.call("PyAggImagePhoto", photoimage, id(aggimage), colormode)
 except (ImportError, AttributeError, Tk.TclError):
 raise
and PyAggImagePhoto is the relevant function which is defined in
src/_tkagg.cpp
static int
PyAggImagePhoto(ClientData clientdata, Tcl_Interp* interp,
 int argc, char **argv)
{
 Tk_PhotoHandle photo;
 Tk_PhotoImageBlock block;
 PyObject* aggo;
 //...snip....
 block.width = aggRenderer->get_width();
 block.height = aggRenderer->get_height();
 //std::cout << "w,h: " << block.width << " " << block.height << std::endl;
 block.pitch = block.width * nval;
 block.pixelPtr = aggRenderer->pixBuffer;
 /* Clear current contents */
 Tk_PhotoBlank(photo);
 /* Copy opaque block to photo image, and leave the rest to TK */
 Tk_PhotoPutBlock(photo, &block, 0, 0, block.width, block.height);
I assume the 0, 0 are the x and y offsets and block.width,
block.height are the sizes of the rect to be transferred. By
following the example of src/_gtkagg.cpp, you should be able to
substitute in the information from the bbox where appropriate.
BTW, I am getting 51 FPS with Tkagg using your blit. My test script
is below:
import matplotlib
matplotlib.use('TkAgg')
import sys
import gtk, gobject
import pylab as p
import matplotlib.numerix as nx
import time
ax = p.subplot(111)
canvas = ax.figure.canvas
# create the initial line
x = nx.arange(0,2*nx.pi,0.01)
line, = p.plot(x, nx.sin(x), animated=True)
def run(*args):
 background = canvas.copy_from_bbox(ax.bbox)
 # for profiling
 tstart = time.time()
 while 1:
 # restore the clean slate background
 canvas.restore_region(background)
 # update the data
 line.set_ydata(nx.sin(x+run.cnt/10.0)) 
 # just draw the animated artist
 ax.draw_artist(line)
 # just redraw the axes rectangle
 canvas.blit(ax.bbox) 
 if run.cnt==200:
 # print the timing info and quit
 print 'FPS:' , 200/(time.time()-tstart)
 sys.exit()
 run.cnt += 1
run.cnt = 0 
manager = p.get_current_fig_manager()
manager.window.after(100, run)
p.show()

I added the blit method to the tkagg, but I don't know what needs to be done to 
take the bbox into account. Even as it stands I get 141 fps in 
animation_blit.py compared to gtk's 350 fps. Whoever is the tk expert, any clue 
on how to account for the bbox on blit updates?
- Charlie
Charles Moad wrote:
> The wiki example works fine. I'll follow that model. You mentioned 
> that only the GtkAgg was supported, but it "appears" that the TkAgg has 
> support as well???
> 
> Thanks as always,
> Charlie
> 
> John Hunter wrote:
> 
>>>>>>> "Charles" == Charles Moad <cm...@in...> writes:
>>
>>
>>
>> Charles> example/animation_blit.py works fine on my laptop, but
>> Charles> for some reason not obvious to me it is not working on my
>> Charles> desktop. Here is the error:
>> Charles> Traceback (most recent call last): File
>> Charles> "animation_blit.py", line 30, in update_line
>> Charles> ax.draw_artist(line) File
>> Charles> "/usr/local/lib/python2.4/site-packages/matplotlib/axes.py",
>> Charles> line 1336, in draw_artist assert self._cachedRenderer is
>> Charles> not None AssertionError
>>
>> Charles> Both machines are up-to-date with cvs. Any clues?
>>
>> The only way to get this error is if you call draw_artist before
>> draw. It could have something to do with the order of the calls in
>> the gtk idle machinery.
>>
>> Try the following which connects to the new "draw_event" to block
>> animation until after draw and background storage
>>
>> # For detailed comments on animation and the techniqes used here, see
>> # the wiki entry
>> # http://www.scipy.org/wikis/topical_software/MatplotlibAnimation
>> import sys
>> import gtk, gobject
>> import pylab as p
>> import matplotlib.numerix as nx
>> import time
>>
>> ax = p.subplot(111)
>> canvas = ax.figure.canvas
>>
>> # for profiling
>> tstart = time.time()
>>
>> # create the initial line
>> x = nx.arange(0,2*nx.pi,0.01)
>> line, = p.plot(x, nx.sin(x), animated=True)
>>
>> # save the clean slate background -- everything but the animated line
>> # is drawn and saved in the pixel buffer background
>> background = None
>>
>> def snap_background(self):
>> global background
>> background = canvas.copy_from_bbox(ax.bbox)
>>
>> p.connect('draw_event', snap_background)
>>
>> def update_line(*args):
>> if background is None: return True
>> # restore the clean slate background
>> canvas.restore_region(background)
>> # update the data
>> line.set_ydata(nx.sin(x+update_line.cnt/10.0)) # just draw 
>> the animated artist
>> ax.draw_artist(line)
>> # just redraw the axes rectangle
>> canvas.blit(ax.bbox) if update_line.cnt==50:
>> # print the timing info and quit
>> print 'FPS:' , 200/(time.time()-tstart)
>> sys.exit()
>>
>> update_line.cnt += 1
>> return True
>> update_line.cnt = 0
>>
>> gobject.idle_add(update_line)
>> p.show()
>>
>>
>>
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> Its good that this fixes the problem, but I don't see why
 Steve> flipping an image upside down should also change its
 Steve> size. There's probably still a bug in there somewhere, but
 Steve> its not too important if the SVG images look correct now.
I just simplified image handling, removing the "origin" arg to the
backend draw_image. In keeping with mpl's philosophy of keeping the
backends simple and dumb, I moved all the origin processing to the
front end.
There is a im.flipud_out() that flips and image upside down for the
backend. This is useful for backends whose default image orientation
is different than matplotlib's (see for example backend_gdk) but is
independent of the "origin" command.
I didn't port these changes to Cairo since I don't have that installed
right now, but Agg, GTK, PS and SVG are working.
JDH

The wiki example works fine. I'll follow that model. You mentioned that only 
the GtkAgg was supported, but it "appears" that the TkAgg has support as well???
Thanks as always,
	Charlie
John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
> Charles> example/animation_blit.py works fine on my laptop, but
> Charles> for some reason not obvious to me it is not working on my
> Charles> desktop. Here is the error:
> Charles> Traceback (most recent call last): File
> Charles> "animation_blit.py", line 30, in update_line
> Charles> ax.draw_artist(line) File
> Charles> "/usr/local/lib/python2.4/site-packages/matplotlib/axes.py",
> Charles> line 1336, in draw_artist assert self._cachedRenderer is
> Charles> not None AssertionError
> 
> Charles> Both machines are up-to-date with cvs. Any clues?
> 
> The only way to get this error is if you call draw_artist before
> draw. It could have something to do with the order of the calls in
> the gtk idle machinery.
> 
> Try the following which connects to the new "draw_event" to block
> animation until after draw and background storage
> 
> # For detailed comments on animation and the techniqes used here, see
> # the wiki entry
> # http://www.scipy.org/wikis/topical_software/MatplotlibAnimation
> import sys
> import gtk, gobject
> import pylab as p
> import matplotlib.numerix as nx
> import time
> 
> ax = p.subplot(111)
> canvas = ax.figure.canvas
> 
> # for profiling
> tstart = time.time()
> 
> # create the initial line
> x = nx.arange(0,2*nx.pi,0.01)
> line, = p.plot(x, nx.sin(x), animated=True)
> 
> # save the clean slate background -- everything but the animated line
> # is drawn and saved in the pixel buffer background
> background = None
> 
> def snap_background(self):
> global background
> background = canvas.copy_from_bbox(ax.bbox)
> 
> p.connect('draw_event', snap_background)
> 
> def update_line(*args):
> if background is None: return True
> # restore the clean slate background
> canvas.restore_region(background)
> # update the data
> line.set_ydata(nx.sin(x+update_line.cnt/10.0)) 
> # just draw the animated artist
> ax.draw_artist(line)
> # just redraw the axes rectangle
> canvas.blit(ax.bbox) 
> 
> if update_line.cnt==50:
> # print the timing info and quit
> print 'FPS:' , 200/(time.time()-tstart)
> sys.exit()
> 
> update_line.cnt += 1
> return True
> update_line.cnt = 0
> 
> gobject.idle_add(update_line)
> p.show()
> 
> 
> 

>>>>> "Charles" == Charles Moad <cm...@in...> writes:
 Charles> example/animation_blit.py works fine on my laptop, but
 Charles> for some reason not obvious to me it is not working on my
 Charles> desktop. Here is the error:
 Charles> Traceback (most recent call last): File
 Charles> "animation_blit.py", line 30, in update_line
 Charles> ax.draw_artist(line) File
 Charles> "/usr/local/lib/python2.4/site-packages/matplotlib/axes.py",
 Charles> line 1336, in draw_artist assert self._cachedRenderer is
 Charles> not None AssertionError
 Charles> Both machines are up-to-date with cvs. Any clues?
The only way to get this error is if you call draw_artist before
draw. It could have something to do with the order of the calls in
the gtk idle machinery.
Try the following which connects to the new "draw_event" to block
animation until after draw and background storage
# For detailed comments on animation and the techniqes used here, see
# the wiki entry
# http://www.scipy.org/wikis/topical_software/MatplotlibAnimation
import sys
import gtk, gobject
import pylab as p
import matplotlib.numerix as nx
import time
ax = p.subplot(111)
canvas = ax.figure.canvas
# for profiling
tstart = time.time()
# create the initial line
x = nx.arange(0,2*nx.pi,0.01)
line, = p.plot(x, nx.sin(x), animated=True)
# save the clean slate background -- everything but the animated line
# is drawn and saved in the pixel buffer background
background = None
def snap_background(self):
 global background
 background = canvas.copy_from_bbox(ax.bbox)
p.connect('draw_event', snap_background)
def update_line(*args):
 if background is None: return True
 # restore the clean slate background
 canvas.restore_region(background)
 # update the data
 line.set_ydata(nx.sin(x+update_line.cnt/10.0)) 
 # just draw the animated artist
 ax.draw_artist(line)
 # just redraw the axes rectangle
 canvas.blit(ax.bbox) 
 
 if update_line.cnt==50:
 # print the timing info and quit
 print 'FPS:' , 200/(time.time()-tstart)
 sys.exit()
 update_line.cnt += 1
 return True
update_line.cnt = 0
gobject.idle_add(update_line)
p.show()

example/animation_blit.py works fine on my laptop, but for some reason not 
obvious to me it is not working on my desktop. Here is the error:
Traceback (most recent call last):
 File "animation_blit.py", line 30, in update_line
 ax.draw_artist(line)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/axes.py", line 1336, 
in draw_artist
 assert self._cachedRenderer is not None
AssertionError
Both machines are up-to-date with cvs. Any clues?
Thanks,
	Charlie
John Hunter wrote:
> I wrote once before
> (http://sourceforge.net/mailarchive/message.php?msg_id=12093643) about
> some new methods for animation that can enable fast animations in
> matplotlib, which can support everything from dynamically updating
> your data to strip charts to real time cursoring to a widget like
> canvas.
> 
> So far, only GTKAgg has complete support for the required methods. I
> think it would be nice to have these in the major mpl GUI backends,
> since it would make the animation interface much simpler and cleaner
> if we could rely on them in the frontend, eg in the Axes class.
> 
> I just posted an entry on the wiki about matplotlib animations. It
> starts with regular "pylab" animations, and then discusses GUI
> animations using timers and event handlers, and finally the newfangled
> methods to support per-artist animations.
> 
> As it turns out, for the *Agg backends, only one new method needs to
> be added, which is 
> 
> canvas.blit(bbox)
> 
> This method transfers the agg canvas within the bounding box onto the
> GUI canvas. I realize that I need to add something like 
> 
> aggcanvas.as_rgba_str(bbox) 
> 
> to support this for Qt and WX which are currently using string methods
> to blit to canvas. I'm happy to do this in the next couple of days if
> I know that someone is interested in actually implementing
> canvas.blit(bbox) for their respective backend.
> 
> To see the utility of the new methods, run examples/widgets/cursor.py
> and examples/widgets/span_selector.py modified to set useblit=True,
> and compare the performance of anim.py with examples/animation_blit.py
> which animate the same data. All of the above should be run done with
> the GTKAgg backend.
> 
> As noted on the wiki entry, with these methods in place, users who
> want to do per artist animation could write code like
> 
> line, = ax.plot(something, animated=True)
> canvas.draw() 
> 
> def callback(*args):
> line.set_ydata(somedata)
> ax.draw_animated()
> 
> 
> This *doesn't* work now, because I am hesitant to put methods into
> Axes which would break most backends. The equivalent in
> animation_blit.py is considerably more complicated.
> 
> Perhaps someone at STScI could sign up for implementing
> canvas.blit(bbox) for TkAgg, and someone at JPL for the Qt backend? I
> might take a crack at WX, if noone else wants it :-) Steve, Gregory
> and Charles, if you are interested in animation for your respective
> backends, I encourage you to take a look at this too. Those of you
> using the agg buffer in extension code (eg tkagg) may want to look at
> src/_gtkagg.cpp to see how the bbox and the agg buffer are used to
> implement blit, which defaults to blitting the entire canvas if
> blit=None. 
> All of this is discussed in more depth at
> http://www.scipy.org/wikis/topical_software/Animations
> 
> Thanks!
> JDH
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Wednesday 03 August 2005 09:02 pm, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
>
> Steve> Its good that this fixes the problem, but I don't see why
> Steve> flipping an image upside down should also change its
> Steve> size. There's probably still a bug in there somewhere, but
> Steve> its not too important if the SVG images look correct now.
>
> That was a different bug, which I fixed too.
>
> 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 reported this problem a while back when I was trying to implement 
draw_markers in backend_ps. Here is the link 
http://sourceforge.net/mailarchive/message.php?msg_id=11371925
-- 
Darren

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> Its good that this fixes the problem, but I don't see why
 Steve> flipping an image upside down should also change its
 Steve> size. There's probably still a bug in there somewhere, but
 Steve> its not too important if the SVG images look correct now.
That was a different bug, which I fixed too.
 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.
Interesting. I've heard of this once before. I'll see if I can find
it.
JDH

On Wed, 2005年08月03日 at 10:27 -0500, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> Steve> One problem with the colorbar is that the png file
> Steve> "im.write_png (filename)" creates is upside down,
> Steve> image_demo.py creates an upside down png too.
> 
> 
> Steve> I see that the GTK/GDK backend does not use im.write_png()
> Steve> but uses im.as_str() which has a 'flipud' argument to flip
> Steve> the image. Is it possible for im.write_png() to take the
> Steve> 'flipud' argument and flip the image for the SVG backend?
> 
> I started working on this, but then realized I would also need to add
> it to buffer_argb32, buffer_rgba and so on, and that is was much
> cleaner to simply add an im.flipud() method than implement it in all
> the conversion and write methods.
> 
> I just committed changes with these fixes and updated backend_ps and
> backend_svg to use them. images in svg appear to be working fine now,
> and the origin = 'lower'|'upper' is respected.
> 
> Steve> The name im.as_str() is a bit vague - what kind of string?
> Steve> Something like im.as_rgba_str() would make it a bit
> Steve> clearer.
> 
> Done.
> 
> JDH
Its good that this fixes the problem, but I don't see why flipping an
image upside down should also change its size. There's probably still a
bug in there somewhere, but its not too important if the SVG images look
correct now.
The SVG backend is also useful for debugging because it gives you a text
list of everything the frontend does. For example I can look at the
output of './simple_plot.py -dSVG' and see that the frontend seems to
have a bug where its drawing every tickline twice. I had a look at
axis.py but could not work out what was going on.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> One problem with the colorbar is that the png file
 Steve> "im.write_png (filename)" creates is upside down,
 Steve> image_demo.py creates an upside down png too.
 Steve> I see that the GTK/GDK backend does not use im.write_png()
 Steve> but uses im.as_str() which has a 'flipud' argument to flip
 Steve> the image. Is it possible for im.write_png() to take the
 Steve> 'flipud' argument and flip the image for the SVG backend?
I started working on this, but then realized I would also need to add
it to buffer_argb32, buffer_rgba and so on, and that is was much
cleaner to simply add an im.flipud() method than implement it in all
the conversion and write methods.
I just committed changes with these fixes and updated backend_ps and
backend_svg to use them. images in svg appear to be working fine now,
and the origin = 'lower'|'upper' is respected.
 Steve> The name im.as_str() is a bit vague - what kind of string?
 Steve> Something like im.as_rgba_str() would make it a bit
 Steve> clearer.
Done.
JDH

This is actually a bug in the Python installer for Solaris as described
in this thread..
http://mail.python.org/pipermail/python-dev/2003-May/035560.html
I changed the following 2 defines in pyconfig.h
#define _XOPEN_SOURCE 500
#define _XOPEN_SOURCE_EXTENDED 0
and it passed that compile error.
ALSO, small bug in the matplotlib setupext.py, on line 531, the Numeric
install does not include the numarray_inc_dirs value to the include
list is is passing into the Extension object. 
S
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

I am trying to build matplotlib on Solaris and am getting the following
compile error. Does this look familiar to anyone?
thanks,
S
In file included from
/work/local-b/sparc-sun-solaris2.9/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/bits/postypes.h:4\
6,
 from
/work/local-b/sparc-sun-solaris2.9/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/iosfwd:50,
 from
/work/local-b/sparc-sun-solaris2.9/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/ios:44,
 from
/work/local-b/sparc-sun-solaris2.9/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/ostream:45,
 from
/work/local-b/sparc-sun-solaris2.9/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/iostream:45,
 from swig/agg_buffer.h:7,
 from src/agg.cxx:1582:
/work/local-b/sparc-sun-solaris2.9/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/../../../../include/c++/3.4.2/cwchar:145:
error: `::btowc' has not been declared
		
__________________________________ 
Yahoo! Mail for Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

I wrote once before
(http://sourceforge.net/mailarchive/message.php?msg_id=12093643) about
some new methods for animation that can enable fast animations in
matplotlib, which can support everything from dynamically updating
your data to strip charts to real time cursoring to a widget like
canvas.
So far, only GTKAgg has complete support for the required methods. I
think it would be nice to have these in the major mpl GUI backends,
since it would make the animation interface much simpler and cleaner
if we could rely on them in the frontend, eg in the Axes class.
I just posted an entry on the wiki about matplotlib animations. It
starts with regular "pylab" animations, and then discusses GUI
animations using timers and event handlers, and finally the newfangled
methods to support per-artist animations.
As it turns out, for the *Agg backends, only one new method needs to
be added, which is 
 canvas.blit(bbox)
This method transfers the agg canvas within the bounding box onto the
GUI canvas. I realize that I need to add something like 
 aggcanvas.as_rgba_str(bbox) 
to support this for Qt and WX which are currently using string methods
to blit to canvas. I'm happy to do this in the next couple of days if
I know that someone is interested in actually implementing
canvas.blit(bbox) for their respective backend.
To see the utility of the new methods, run examples/widgets/cursor.py
and examples/widgets/span_selector.py modified to set useblit=True,
and compare the performance of anim.py with examples/animation_blit.py
which animate the same data. All of the above should be run done with
the GTKAgg backend.
As noted on the wiki entry, with these methods in place, users who
want to do per artist animation could write code like
 line, = ax.plot(something, animated=True)
 canvas.draw() 
 def callback(*args):
 line.set_ydata(somedata)
 ax.draw_animated()
This *doesn't* work now, because I am hesitant to put methods into
Axes which would break most backends. The equivalent in
animation_blit.py is considerably more complicated.
Perhaps someone at STScI could sign up for implementing
canvas.blit(bbox) for TkAgg, and someone at JPL for the Qt backend? I
might take a crack at WX, if noone else wants it :-) Steve, Gregory
and Charles, if you are interested in animation for your respective
backends, I encourage you to take a look at this too. Those of you
using the agg buffer in extension code (eg tkagg) may want to look at
src/_gtkagg.cpp to see how the bbox and the agg buffer are used to
implement blit, which defaults to blitting the entire canvas if
blit=None. 
All of this is discussed in more depth at
http://www.scipy.org/wikis/topical_software/Animations
Thanks!
JDH

On Mon, 2005年08月01日 at 20:26 -0700,
mat...@li... wrote:
> 
> In some cases, there appears to be a bug in SVG image
> handling. For
> example, the image in the colorbar is not properly sized
> 
> import pylab as p
> p.imshow(p.rand(5,3))
> p.colorbar()
> p.savefig('test.svg')g
> p.show()
> 
> This problem appeared before and after Steve's application of
> Norbert's PNG patch (thanks's Norbert!) so it looks like
> something
> else is to blame. 
One problem with the colorbar is that the png file "im.write_png
(filename)" creates is upside down, image_demo.py creates an upside down
png too.
I see that the GTK/GDK backend does not use im.write_png() but uses
im.as_str() which has a 'flipud' argument to flip the image.
Is it possible for im.write_png() to take the 'flipud' argument and flip
the image for the SVG backend?
The name im.as_str() is a bit vague - what kind of string? Something
like im.as_rgba_str() would make it a bit clearer.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com