Re: TKinter : 'module' object has no attribute 'tkinit'

As it happens, the box I was working on totally borked (hardware 
problem).  I've built a CentOS box and am running fine now --- I made a 
point of installing X, gtk, cairo, tcl, tk and other graphics libs 
before building python and matplotlib on the box.

So, the problems seems to be related to the way python and/or Tkinter 
was built.  X was not on the box when I built python initially.

* shrug *

Things work nicely now.

Michael Droettboom wrote:
> It doesn't look like a faulty X setup, and since you *do* get a 
> window, it's unlikely it's a Tkinter problem.
>
> The fishy thing here is that _tkagg should be a C extension, have a 
> .so file extension and have only the following members -->
>
> >>> dir(_tkagg)
> ['__doc__', '__file__', '__name__', '_pyobj_addr', 'tkinit']
>
> tkagg (without the underscore), on the other hand, is a true Python 
> module, would have a .pyc extension and all of the members you posted.
>
> So, somehow, tkagg got renamed to _tkagg on your system.  I'm not sure 
> how the build script may have done that.  Does removing
>
>  /usr/lib/python2.5/site-packages/matplotlib/backends/_tkagg.pyc
>

Improved histogram w/multiple types

I've made some alterations to the hist() function in axes.py (attached
is a diff against the current SVN version).  I've added the capability
to use the same interface to make outline histograms instead of bar
histograms (and a third option for outlines with fill - note that this
is NOT the same as calling it twice with the other two, as the widths
are slightly different).  There's a slight compatibility issue in that
as it stands in that the returned tuple now has 4 values (I added a
list of the lines that are generated if the steps command is used),
but I can't really imagine how that could break anything but the
poorest-written code...  Anyone think this is worth committing to SVN?

(One thing that bothers me a little is the part of the code that adds
the last two edges to the histogram - the problem is that if you have
a line size greater than 1, the outline overshoots the rest of the
outline by a very tiny bit... if anyone knows how to cut off the upper
row of pixels to make it flush with the rest of the outline... it's
perfectly usable as-is, though - that's just a tiny little aesthetic
quibble)

--

-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
4155B Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2996
Cell: (651)307-9409
etolleru@...

where's draw_point gone ?

Hi,

in matplotlib 0.91 there was a function draw_point for the backends. 
This seems to be gone (except for backend_agg2.py and backend_emf.py 
!?). I guess it wasn't used very often; instead I see that there is now 
a function draw_point in lines.py. Is it possible to re-add this 
functionality to the backends ??? What I would need is a function that 
draws a single pixel to a device.

The reason why I'm asking is that I have thought about an additional 
scatter marker m=(0,0) that draws single pixels (as fast as possible). 
Such a marker might be very useful when drawing lots and lots of 
data-point on in a single plot. A typical application might be to draw 
the positions of particles in an N-Body simulation. My current best 
approach is to use "scatter(x,y, s=0.1)", but I think that an optimized 
routine would be very helpful.

So my main questions are:
- Why was draw_point removed ?
- Can it be re-added again?

Manuel

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: where's draw_point gone ?

On Thu, Apr 3, 2008 at 8:40 AM, Manuel Metz
<mmetz@...> wrote:
> Hi,
>
>  in matplotlib 0.91 there was a function draw_point for the backends.
>  This seems to be gone (except for backend_agg2.py and backend_emf.py
>  !?). I guess it wasn't used very often; instead I see that there is now
>  a function draw_point in lines.py. Is it possible to re-add this
>  functionality to the backends ??? What I would need is a function that
>  draws a single pixel to a device.

The markerstyle for drawing a pixel is ',' and it is supported across
backends AFAIK

In [1]: plot(rand(1000), ',')
Out[1]: [<matplotlib.lines.Line2D instance at 0x8e6c12c>]

In [2]: savefig('test.png')

In [3]: savefig('test.pdf')

In [4]: savefig('test.eps')

In [5]: savefig('test.svg')

JDH

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for

Problem in qtagg and qt4agg backends

A few weeks ago I reported a double draw problem in the qt backends.  They
both have a draw() method that looked like this:

    def draw( self ):
        self.replot = True
        FigureCanvasAgg.draw(self)
        self.repaint( False )

It turned out that FCA::draw() and self.repaint() both did a draw which
slowed everything down.  Commenting out the FCA draw call seemed to work
fine:

    def draw( self ):
        self.replot = True
        self.repaint( False )

However, this breaks when running code like this:

import pylab as p
p.plot( [1,2,3] )
p.savefig( 'image.png' )

The image is never drawn in this case.  If you do a show() and save the
image from the gui, then everything is fine.  I did some experimenting and
the solution may be to do this:

    def draw( self ):
        self.replot = True
        FigureCanvasAgg.draw(self)

Re: where's draw_point gone ?

John Hunter wrote:
> On Thu, Apr 3, 2008 at 8:40 AM, Manuel Metz
<mmetz@...> wrote:
>> Hi,
>>
>>  in matplotlib 0.91 there was a function draw_point for the backends.
>>  This seems to be gone (except for backend_agg2.py and backend_emf.py
>>  !?). I guess it wasn't used very often; instead I see that there is now
>>  a function draw_point in lines.py. Is it possible to re-add this
>>  functionality to the backends ??? What I would need is a function that
>>  draws a single pixel to a device.
> 
> The markerstyle for drawing a pixel is ',' and it is supported across
> backends AFAIK

Hi John,
thank - that's done via the draw_point in lines.py, right? Now, as far 
as I can see this function "emulates" to draw one pixel by drawing a 
line of length 1 pixel. I was just wondering whether its worth to have a 
draw_point method for (pixel-based) backends (png) that have an 
intrinsic command to draw one pixel which might be more efficient.

But if it's done with lines for all the backends, this means that 
draw_point() can be removed from the two files backend_agg2.py and 
backend_emf.py !?

Manuel

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.

Re: where's draw_point gone ?

Manuel Metz wrote:
> John Hunter wrote:
>   
>> On Thu, Apr 3, 2008 at 8:40 AM, Manuel Metz
<mmetz@...> wrote:
>>     
>>> Hi,
>>>
>>>  in matplotlib 0.91 there was a function draw_point for the backends.
>>>  This seems to be gone (except for backend_agg2.py and backend_emf.py
>>>  !?). I guess it wasn't used very often; instead I see that there is now
>>>  a function draw_point in lines.py. Is it possible to re-add this
>>>  functionality to the backends ??? What I would need is a function that
>>>  draws a single pixel to a device.
>>>       
>> The markerstyle for drawing a pixel is ',' and it is supported across
>> backends AFAIK
>>     
>
> Hi John,
> thank - that's done via the draw_point in lines.py, right? Now, as far 
> as I can see this function "emulates" to draw one pixel by drawing a 
> line of length 1 pixel. I was just wondering whether its worth to have a 
> draw_point method for (pixel-based) backends (png) that have an 
> intrinsic command to draw one pixel which might be more efficient.
>   
In Agg at least, it won't be much more efficient -- the marker is drawn 
only once and then blitted multiple times.  There's some overhead for 
the blitting loop, for sure, but not much -- probably not enough to 

improvements to color validation in rcsetup.py

matplotlib.rcsetup.validate_color() currently regards a variety of
invalid color strings as valid. I created a patch (relative to
matplotlib 0.91.2) that improves the validation performed by said
function. Ought I post it here? I tried to post it as a bug on
SourceForge, but the site refused the upload with a message indicating
the size limitation of bug attachments even though my patch is well
within that limit.

							L.G.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: Unnecessary rerendering in wx/wxagg backends

I continued to work on this issue. Thanks for Chris Barker for pointing 
me into the right direction. I also had a look at other gui backends, 
and, among other, backend_qtagg.py seems to contain a proper (more or 
less, see other postings of Ted Drain) implementation of double buffered 
drawing that avoids unnecessary rerendering of the bitmap. Following 
this example, I applied following changes to backend_wx.py and 
backend_wxagg.py

backend_wx.py:

in __init__(...) added line:

self._need_rerender = True

changed _onPaint(...) to following (note: removed evt.Skip() at end!)

    def _onPaint(self, evt):
        """
        Called when wxPaintEvt is generated
        """
        DEBUG_MSG("_onPaint()", 1, self)
        if not self._isRealized:
            self.realize()
        #only recreate bitmap if needed
        if self._need_rerender:
            self.draw(repaint=False)
            self._need_rerender = False
        #repaint only damaged parts of window
        dc = wx.PaintDC(self)
        source = wx.MemoryDC(self.bitmap)

Re: Unnecessary rerendering in wx/wxagg backends

Here I attached diff files of my changes, compared to matplotlib-0.91.2 
release.

Gregor Thalhammer

--- Kopie von backend_wx.py	Mon Mar 31 10:28:22 2008
+++ backend_wx.py	Sun Apr  6 10:23:09 2008
@@ -752,11 +752,14 @@
         self._isRealized = False
         self._isConfigured = False
         self._printQued = []
+        self._need_rerender = True

         if wx.VERSION_STRING >= '2.5':
             # Event handlers 2.5
             self.Bind(wx.EVT_SIZE, self._onSize)
             self.Bind(wx.EVT_PAINT, self._onPaint)
+            #self.Bind(wx.EVT_ERASE_BACKGROUND, self._onEraseBackground)
+            #self.Bind(wx.EVT_IDLE, self._onIdle)
             self.Bind(wx.EVT_KEY_DOWN, self._onKeyDown)
             self.Bind(wx.EVT_KEY_UP, self._onKeyUp)
             self.Bind(wx.EVT_RIGHT_DOWN, self._onRightButtonDown)
@@ -952,7 +955,8 @@
         self.renderer = RendererWx(self.bitmap, self.figure.dpi)
         self.figure.draw(self.renderer)
         if repaint:
-            self.gui_repaint()
+            self.Refresh()
+            #gui_repaint()