matplotlib-devel Mailing List for matplotlib (Page 4)

referring to: 
http://news.gmane.org/find-root.php?message_id=%3cc7009a550804100055g6388b20ej520e85d8e679a55%40mail.gmail.com%3e

There was a slightly jumbled set of threads on Numpy-discussion that 
included a discussion of standardizing imports, like this:

import numpy as np
import scipy as sp

and then this was added, as something else that had been agreed at the 
same sprint:

import pylab as plt

I think this is a mistake, and it should have been

import matplotlib.pyplot as plt

because, for most production code, we don't want to be accessing numpy 
indirectly via pylab.  I suspect it was just a slip-up by the poster, 
but since I was not involved in whatever discussion led to "plt", and 
the thread was going in several directions at once, I did not want to 
jump in.

We should get this straight, however.  Note that the point is not to 
tell users that they must use a particular form, but to try to 
standardize the usage in the projects themselves, including examples and 
documentation, so as to reduce confusion among new users.

Eric

Darren Dale wrote:

> I reverted the changes, so we still have an unnecessary call to draw in some 
> cases, but at least everything should work.

There are similar issues with the wx back-end (see the recent thread). 
The proposed patch to wx should be tested in interactive mode. If it 
works, then maybe it can be ported to QT. If it doesn't then this makes 
it quite clear that some re-factoring is needed:

As I looked through the wx code, I found it to be a bit of a jumbled 
mess of blitting and drawing and... It looks like it has grown out of a 
simpler system, with various patches to fix things that didn't work, 
eventually ending up with "re-draw every time you paint", which should 
work (and does), but really kills the whole idea of double buffering.

Anyway, it should be structured something like:

In the Paint handler:
Only a blit of the buffer bitmap -- that it, ever. In the case of the 
Agg back-ends, I don't know if there should be both the Agg bitmap and a 
native (wx, qt, or gtk) bitmap -- I suppose that's a function of how 
fast it is to go from agg to native bitmap -- I think this can be now 
done on wx without any data copying, so it should be fast enough. If 
not, then the native and agg bitmaps should always be kept in sync.

When should the bitmap be re-drawn?

1) On a Size event -- so a Size event handler needs to call 
canvas.draw() (is that right?)

2) when the users code or MPL asks for a re-draw -- this is the 
canvas.draw() call, I think.

It should be as simple as that! Or are there other times that the bitmap 
needs to be re-drawn?

One complication -- when the canvas is re-drawn due to a user action, 
the screen needs to be updated, so we need a "blit the bitmap to the 
screen now" call, which would be made after every canvas.draw() call, 
unless it's a SaveFig or printing call. On wx, the theory is that you 
can call Refresh() and Update(), which will trigger a Paint event. 
However, I've found that that sometimes doesn't happen right away -- 
it's fast enough for common use, but not for animation, so I suggest 
that there be a BlitNow() method that uses a wx.ClientDC to blit the 
bitmap. I don't know about QT or GTK.

I have noticed a bunch of code that computes the damaged region of the 
window, so that only that part gets blitted -- in theory that's a nice 
optimization, but in practice, I've found that bltting the whole window 
is plenty fast, so there's little point.

I wish I had more time to work on this...

-Chris







-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

On Thursday 03 April 2008 05:52:28 pm Ted Drain wrote:
> 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)
>
> Which does seem to work for the cases I have.  Could someone else take a
> look and see if this doesn't break anything (You'll have to edit your local
> backends, I haven't changed anything).

That change causes all kinds of problems with interactive plotting. I tested 
the following with ipython -pylab:

a=rand(10,10)
im=imshow(a)
b=rand(10,10)
im.set_data(b)
draw() # nothing happens, lets start over

a=rand(10,10)
im=imshow(a)
b=rand(10,10)
im=imshow(b) # No change, lets close the window and try again
im=imshow(b) # no figure is created
show() # still no figure

I reverted the changes, so we still have an unnecessary call to draw in some 
cases, but at least everything should work.

Darren

I'be been playing around with this for a while and can't seem to get it.

I'm running qt4 with a twisted python reactor (the qtreactor I maintain
for the twisted folks).

I'm doing an animated scrolling plot... all works great but I want to
rescale the plot as the ranges change.  That works as well and I know
the information is in the axes because if I change the size of the plot,
they redraw correctly... but I can't figure out what call to make inside
the loop to force the axes to redraw...

This is probably really simple... but I've tried just about every call I
can think of and it just won't recalc...

any hints?

-glenn

-- 
Glenn H. Tarbox, PhD    

Gregor,

Thanks for working on this.

> 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.

It still feels a bit kludgy to me -- a paint event should simply copy
the bitmap to the screen, any re-rendering should be triggered by other
events -- either a re-size, or explicitly by figure.canvas.draw() or
something. Anyway, given the current structure, this looks like the way
to go.

> self._need_rerender = True

Where does this get set to True again? On a Figure.canvas.draw() call?

> changed _onPaint(...) to following (note: removed evt.Skip() at end!)
>    def _onPaint(self, evt):

>        #repaint only damaged parts of window

I don't know that this is needed, bitting the whole Window is blazingly
fast anyway -- but if it works, why not?

>        dc = wx.PaintDC(self)
>        source = wx.MemoryDC(self.bitmap)
>        box = self.UpdateRegion.Box
>        dc.Blit(box.X, box.Y, box.Width, box.Height,
>                source,
>                box.X, box.Y)
>        source.SelectObject(wx.NullBitmap) #needed?

no, it goes away at the end of the method, anyway.


> By these change in onPaint a rerendering of the bitmap is done only if
> needed (in fact, this is needed only once after the figure is shown
> for the first time).

Well, it's needed whenever the figure changes -- on each
figure.canvas.draw() call, I guess.

> I moved code from gui_repaint() into
> _onPaint. Calls to gui_repaint() in other methods (e.g., draw) might now be
> replaced by
> 
> self.Refresh()
> self.Update() #this is optional, leeds to an immediate repaint

Maybe -- I've found (at least on OS-X) that using a ClientDC is still
required sometimes to get instant response. This is key if you're doing
anything like animation.

>    def draw(self, repaint=True):
>        """
>        Render the figure using agg.
>        """
>        DEBUG_MSG("draw()", 1, self)
>              FigureCanvasAgg.draw(self)
>        self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
>        if repaint:
>            self.Refresh(eraseBackground = False)
>            self.Update()

I think maybe these should be calls to gui_repaint, which will get you
to a ClientDC instead of waiting for a paint event -- Update is not
always instant.

>        self.Update() #needed?

Same as above.

> I had to add some calls to figure.canvas.draw in my mpl-embedded-in-wx
> application, e.g., after changing a colormap range, to give a
> immediate change on screen. Before due to the frequent rerendering I
> didn't notice that these statements were missing.

I agree -- I think I'm going to need to add a few of those too. The
problem is that this is a change, and other folks' code is going to
break too.

> As Chris Barker noticed, Figure.draw() does not lead to a repainting
> of the window on screen. This seems to be intended. Instead one should
> use pylab.draw() or Figure.canvas.draw().

I think you're right -- I should have looked at the pylab.draw code to
see what it did. Though I think Figure should have a method that does do
an instant update...DrawNow??

> I thought about a more substantial rewrite of the Wx/WxAgg backend,
> similar to the QtAgg backend,

I think it does kind of need it.

> Anyhow, the Wx backend seems to be in some
> aspects outdated (uses old style wx methods, e.g. ToolBar.AddTool) and
> is even not fully functional (image support missing). What are the
> plans for the future?

Well, I think most folks use wxAgg, rather than the straight wx
back-end. As for other updating -- it's not a matter of plans so much as
someone needing to step up and do it!

> What about the politics of supporting older versions of wxWidgets?

I wouldn't bother, but I'm a bleeding-edge kind of guy. It seems that we
could at least make sure not to break anything by keeping the old code
around for older versions, and go all 2.8 for new code, with one big 'ol
version test at the top of the modules.

Thanks for working on this,

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Hi,

In learning to make a nice plot for a small window on a web page,
I had to go through a number of contortions to get the layout correct.

Graph layout should be based on em and ex spacing rather than
portion of the viewable area.  The attached file computes the
portions as best it can based on the font size (I don't know if
em and ex are readily available).  It still isn't right.  In
particular, the legend box width can't be controlled properly,
or the distance between legend and one graph edge since there
is one number for each of axespad and pad regardless of aspect ratio.

I propose allowing all dimensions to carry units with them: 
    point, pixel, font, axis, figure or data
The x and y dims may have different units.  Even for the same 
units, the x and y will be different because of aspect ratio.

I would suggest allowing string values such as:
    '10pt', '14px', '1ch', '0.01ax', '0.01fig', '35d'
or pairs:
    (10,'pt'), (14,'px'), ...

The OOP trick of 10*pt, 14*px, etc. is cute, but the names need
to be much longer for this to work.

The transform= kw on some entries would no longer be necessary.

I won't have time to code this for a long time, but I wanted 
to get it out there while it is fresh in my mind, and give
people a chance to comment on it.

A further note: small/medium/large aren't quite what I wanted
for relative font sizes.  It would be nice to be able to specify
0.9x/1x/1.1x instead.

	- Paul

Lev,

It looks to me like you have stumbled on either a bug or a feature--and 
I think it is the former--so I have moved this over to the devel list.

The code for handling font defaults in FontProperties is tricky, and I 
am not sure I understand it correctly.  It looks like it is setting up 
defaults in the FontPropertiesSet class, and those defaults should be 
effectively pointers to the corresponding rcParams values. (They are 
single-element lists.) However, it looks like this clever scheme is 
being subverted by all the set_* methods of FontProperties, which are 
called when the instance is initialized, and which seem to be discarding 
(via the pop method) all of the initial values--the pointers.

Most likely I am missing something, and it will be more efficient if 
someone closer to this part of the code can take a look and enlighten 
me, or fix the problem, or explain why this is a feature and not a bug.

Eric


Lev Givon wrote:
> Using matplotlib 0.91.2 with the current development version of
> ipython on Linux with no local matplotlibrc file, I have noticed that
> setting the font weight via
> 
> rc('text',fontweight='bold')
> 
> or 
> 
> rc('font',weight='bold')
> 
> changes the relevant rc parameter but doesn't affect the weight of the
> displayed fonts used in the axes or titles. Specifying the weight in
> matplotlibrc does work, however. Has anyone else observed this?
> 
> 	     	  		     	    	 L.G.
> 
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Lev,

I'm sorry, but you went a little too far in the new version; color 
validation in rcsetup still needs much of the original code, but it can 
use is_color_like as a helper--not a replacement. validate_color has to 
handle 'None', and tuples that come in as strings.

I have committed a change to svn that I think takes care of the problem. 
  It could be simplified, or it could be made more complex by adding 
more explanation of what is wrong with a given input, but I think it is 
adequate for now as-is.  It should trap anything that would otherwise 
fail later.

Eric

Lev Givon wrote:
> Received from Lev Givon on Sun, Apr 06, 2008 at 11:03:06PM EDT:
>> Received from Eric Firing on Sun, Apr 06, 2008 at 10:40:44PM EDT:
>>> Lev,
>>>
>>> Yes, you can post it here.  It looks to me like just using 
>>> colors.is_color_like() as a last step would do it.  Is that the way you 
>>> made the change? I haven't dealt much with the rc system, so I may be 
>>> missing something.
>>>
>> No, but your suggestion seems preferable to my patch (I essentially
>> just improved several problematic clauses within validate_color and
>> added a check against the color name dictionaries defined in
>> matplotlib.color). There may be some issue complicating the import of
>> the color module within rcsetup, though; I will have to check.
> 
> The issue I alluded to affects the current stable version of
> matplotlib owing to the numerix layer, but isn't a problem with the
> svn version. The updated patch (made against revision 4913 of
> rcsetup.py) is attached.
> 
> 							L.G.
> 
> 
> ------------------------------------------------------------------------
> 
> --- rcsetup.py.bak	2008-04-07 11:46:47.000000000 -0400
> +++ rcsetup.py	2008-04-07 12:33:06.000000000 -0400
> @@ -10,6 +10,7 @@
>  
>  import os
>  from matplotlib.fontconfig_pattern import parse_fontconfig_pattern
> +from matplotlib.colors import is_color_like
>  
>  class ValidateInStrings:
>      def __init__(self, key, valid, ignorecase=False):
> @@ -125,34 +126,11 @@
>  
>  def validate_color(s):
>      'return a valid color arg'
> -    if s.lower() == 'none': return 'None'
> -    if len(s)==1 and s.isalpha(): return s
> -    if s.find(',')>=0: # looks like an rgb
> -        # get rid of grouping symbols
> -        s = ''.join([ c for c in s if c.isdigit() or c=='.' or c==','])
> -        vals = s.split(',')
> -        if len(vals)!=3:
> -            raise ValueError('Color tuples must be length 3')
> -
> -        try: return [float(val) for val in vals]
> -        except ValueError:
> -            raise ValueError('Could not convert all entries "%s" to floats'%s)
> -
> -    if s.replace('.', '').isdigit(): # looks like scalar (grayscale)
> +    if is_color_like(s):
>          return s
> -
> -    if len(s)==6 and s.isalnum(): # looks like hex
> -        return '#' + s
> -
> -    if len(s)==7 and s.startswith('#') and s[1:].isalnum():
> -        return s
> -
> -    if s.isalpha():
> -        #assuming a color name, hold on
> -        return s
> -
> -    raise ValueError('%s does not look like color arg'%s)
> -
> +    else:
> +        raise ValueError('%s does not look like color arg'%s)
> +    
>  def validate_stringlist(s):
>      'return a list'
>      if type(s) is str:
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Received from Lev Givon on Sun, Apr 06, 2008 at 11:03:06PM EDT:
> Received from Eric Firing on Sun, Apr 06, 2008 at 10:40:44PM EDT:
> > Lev,
> >
> > Yes, you can post it here.  It looks to me like just using 
> > colors.is_color_like() as a last step would do it.  Is that the way you 
> > made the change? I haven't dealt much with the rc system, so I may be 
> > missing something.
> >
> 
> No, but your suggestion seems preferable to my patch (I essentially
> just improved several problematic clauses within validate_color and
> added a check against the color name dictionaries defined in
> matplotlib.color). There may be some issue complicating the import of
> the color module within rcsetup, though; I will have to check.

The issue I alluded to affects the current stable version of
matplotlib owing to the numerix layer, but isn't a problem with the
svn version. The updated patch (made against revision 4913 of
rcsetup.py) is attached.

							L.G.

Manuel Metz wrote:
> Paul Smith wrote:
>> I'm plotting two curves in one subplot with twinx to allow different y 
>> scales. The script below is an example. When zooming in using 
>> zoom-to-rect on Tk's navigation toolbar2 (TkAgg is my backend) I think 
>> the x axis part of the zoom is happening twice. Rubberbanding the 
>> example from x=20 to 80 results in a zoomed x range of about 32 to 68, 
>> which is about what you'd expect for zooming with the same range twice.
>> Is there a way of restricting this to only one zoom?
>>
>> Paul
>> ------------
>> from pylab import *
>> f=figure(1)
>> ax1=f.add_subplot(111)
>> ax1.plot(arange(100))
>> ax2=twinx(ax1)
>> ax2.plot(-arange(100),'g')
>> draw()
>>
> 
> Hi,
> there was the above mail on the users list.
> 
> The problem is that "release_zoom" in backend_bases.py is called twice 
> in the above case if zoomed to a twinx'ed plot. One way to fix this 
> behavior is to set a "twin" attribute to the axes instance. Attached is 
> a patch against the 0.91 trunk.
> 
> John: is this okay or is there a better way to fix the problem?
> 
> Manuel
> 

Ups - the last patch didn't work correctly since the y-axis of the 
twin'ed plot wasn't scaled correctly. So I try it again ;-)

Manuel

Paul Smith wrote:
> I'm plotting two curves in one subplot with twinx to allow different y scales. 
> The script below is an example. 
> When zooming in using zoom-to-rect on Tk's navigation toolbar2 (TkAgg is my 
> backend) I think the x axis part of the zoom is happening twice. Rubberbanding 
> the example from x=20 to 80 results in a zoomed x range of about 32 to 68, 
> which is about what you'd expect for zooming with the same range twice. 
> 
> Is there a way of restricting this to only one zoom?
> 
> Paul
> ------------
> from pylab import *
> f=figure(1)
> ax1=f.add_subplot(111)
> ax1.plot(arange(100))
> ax2=twinx(ax1)
> ax2.plot(-arange(100),'g')
> draw()
> 

Hi,
there was the above mail on the users list.

The problem is that "release_zoom" in backend_bases.py is called twice 
in the above case if zoomed to a twinx'ed plot. One way to fix this 
behavior is to set a "twin" attribute to the axes instance. Attached is 
a patch against the 0.91 trunk.

John: is this okay or is there a better way to fix the problem?

Manuel

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

Gregor Thalhammer

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)
        box = self.UpdateRegion.Box
        dc.Blit(box.X, box.Y, box.Width, box.Height,
                source,
                box.X, box.Y)
        source.SelectObject(wx.NullBitmap) #needed?

By these change in onPaint a rerendering of the bitmap is done only if
needed (in fact, this is needed only once after the figure is shown
for the first time). I moved code from gui_repaint() into
_onPaint. Calls to gui_repaint() in other methods (e.g., draw) might now be
replaced by

self.Refresh()
self.Update() #this is optional, leeds to an immediate repaint

in backend_wxagg.py I changed the draw and blit methods in this sense:

    def draw(self, repaint=True):
        """
        Render the figure using agg.
        """
        DEBUG_MSG("draw()", 1, self)
       
        FigureCanvasAgg.draw(self)
        self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
        if repaint:
            self.Refresh(eraseBackground = False)
            self.Update()
    def blit(self, bbox=None):
        self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
       
        if bbox is None:
            self.Refresh(eraseBackground = False)
        else:
            l, b, w, h = bbox.get_bounds()
            x = int(l)
            y = int(self.bitmap.GetHeight() - (b+h))
            w = int(w)
            h = int(h)
            self.RefreshRect(wx.Rect(x, y, w, h),
                             eraseBackground = False)
        self.Update() #needed?


I tested these changes with WinXP, python2.5, matplotlib 0.91.2,
wxWidgets2.8.7 with several scripts from the matplotlib/examples and I
could not observe a misbehaviour.

I had to add some calls to figure.canvas.draw in my mpl-embedded-in-wx
application, e.g., after changing a colormap range, to give a
immediate change on screen. Before due to the frequent rerendering I
didn't notice that these statements were missing.

As Chris Barker noticed, Figure.draw() does not lead to a repainting
of the window on screen. This seems to be intended. Instead one should
use pylab.draw() or Figure.canvas.draw().

I thought about a more substantial rewrite of the Wx/WxAgg backend,
similar to the QtAgg backend, but (for the moment) I wanted to try
only simple changes. Anyhow, the Wx backend seems to be in some
aspects outdated (uses old style wx methods, e.g. ToolBar.AddTool) and
is even not fully functional (image support missing). What are the
plans for the future? What about the politics of supporting older
versions of wxWidgets?

Gregor Thalhammer

Christopher Barker schrieb:
> Erik Tollerud wrote:
>   
>> I tested this on 0.91.2 on Ubuntu Gutsy, and wx 2.8.7.1, and found
>> that when I bring up a new window, I see a black canvas and it doesn't
>> draw any of the matplotlib objects until I do something like resizing
>> that must explicitly call a draw at some point.
>>     
>
> yup, same here.
>
> I'm using wxAgg, and FigureCanvas.draw() just doesn't seem to be getting 
> called when I call Figure.draw()
>
> It looks like it's designed to work the other way -- the Window needs to 
> call self.figure.draw(self.renderer) when it wants the image drawn. 
> There is an efficiency to this, as the figure doesn't get rendered until 
> the GUI toolkit needs it. However, having it re-render on every Paint 
> call isn't right either.
>
> So how should this work? I'd like to be able to call Figure.draw(), and 
> have the figure re-draw itself - but then it needs to be able to tell 
> the backend Canvas that it needs to be drawn.
>
> It seems that the figure needs to keep a flag that indicated when it is 
> "dirty", then the paint handler could check that, and call draw if need 
> be. Is there one already?
>
> This all seems a bit awkward though. I've written a bunch of double 
> buffered code, and I try to do it like this:
>
> The Paint handler only blits.
> There is a draw routine that actually draws the off-screen bitmap. It is 
> called:
>    - when the bitmap is new, like in a Re-size event
>    - when the drawing changes.
>
> In the MPL case, then, it seems that figure.draw() should call that draw 
> routine, but maybe it doesn't know anything about its canvas. Ah -- ye 
> sit does - figure.canvas.
>
> OK, so a draw_event is getting called, which I guess is where the 
> drawing should happen, but I'm getting lost now!
>
> -Chris
>   

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.

Manuel Metz wrote:
> John Hunter wrote:
>   
>> On Thu, Apr 3, 2008 at 8:40 AM, Manuel Metz <mm...@as...> 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 
warrant complicating the code.  But, I say that without any experiments, 
so I'm happy to be proven wrong.
> 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 !?
>   
Both of those backends are deprecated anyway -- probably best to just 
remove the backends altogether... ;)

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Thu, Apr 3, 2008 at 8:40 AM, Manuel Metz <mm...@as...> 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

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)

Which does seem to work for the cases I have.  Could someone else take a
look and see if this doesn't break anything (You'll have to edit your local
backends, I haven't changed anything).

Ted

On Thu, Apr 3, 2008 at 8:40 AM, Manuel Metz <mm...@as...> 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

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

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
eto...@uc...

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
>
> help?  (It's generally safe to remove .pyc files since they are 
> regenerated by the Python compiler).  Do you have a _tkagg.py sitting 
> in that directory?
>
> Did you build matplotlib from the source tarball, a Gentoo port (or 
> whatever they're called), or some other way?
>
> If you built yourself, (even if the above suggestion worked), could 
> you try cleanly rebuilding again by:
>
>  1. deleting the build directory under the source tree
>  2. deleting /usr/lib/python2.5/site-packages/matplotlib
>  3. "python setup.py install"
>
> and let us know if that worked?
>
> Cheers,
> Mike
>
> Darren Dale wrote:
>> Do you have the tk-devel packages installed? When you run setup.py, 
>> there is a report at the beginning which lists all the required and 
>> optional dependencies, would you post that?
>>
>> On Friday 21 March 2008 08:52:40 am fiacre wrote:
>>  
>>> I agree -- I don't believe it built correctly either ...
>>>
>>> Python 2.5.1 (r251:54863, Mar 20 2008, 04:03:41)
>>> [GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>  >>> from matplotlib.backends import _tkagg
>>>  >>> _tkagg.__file__
>>>
>>> '/usr/lib/python2.5/site-packages/matplotlib/backends/_tkagg.pyc'
>>>
>>>  >>> dir(_tkagg)
>>>
>>> ['AxisMenu', 'Figure', 'FigureCanvasAgg', 'FigureCanvasBase',
>>> 'FigureCanvasTkAgg', 'FigureManager', 'FigureManagerBase',
>>> 'FigureManagerTkAgg', 'FileDialog', 'Gcf', 'GraphicsContextBase',
>>> 'NavigationToolbar', 'NavigationToolbar2', 'NavigationToolbar2TkAgg',
>>> 'PIXELS_PER_INCH', 'RendererBase', 'SubplotTool', 'Tk', '__builtins__',
>>> '__doc__', '__file__', '__name__', 'asarray', 'backend_version',
>>> 'cursord', 'cursors', 'division', 'draw_if_interactive', 'enumerate',
>>> 'error_msg_tkpaint', 'is_string_like', 'math', 'matplotlib',
>>> 'new_figure_manager', 'os', 'raise_msg_to_str', 'rcParams', 'round',
>>> 'show', 'sys', 'tkagg', 'verbose', 'windowing']
>>>
>>>
>>>
>>> I don't see anything obviously wrong though -- I am wondering if my X
>>> setup is faulty.
>>>
>>> Thanks!
>>>
>>> Michael Droettboom wrote:
>>>    
>>>> It looks like the _tkagg C extension didn't build correctly -- it
>>>> really should have a tkinit method.
>>>>
>>>> Can you please try the following and send me the output (inside the
>>>> Python interpreter)...
>>>>
>>>>      
>>>>>>> from matplotlib.backends import _tkagg
>>>>>>> _tkagg.__file__
>>>>>>> dir(_tkagg)
>>>>>>>             
>>>> Thanks!
>>>>
>>>> Mike
>>>>
>>>> fiacre wrote:
>>>>      
>>>>> I'm running Idle via X forwarding to my Windows desktop (running
>>>>> Cygwin).
>>>>>
>>>>> I've installed tcl/tk and python with Tkinter as a backend.
>>>>>
>>>>> When I call pylab.show(),  I always get the error :
>>>>>  >>> pylab.show()
>>>>>
>>>>> Exception in Tkinter callback
>>>>> Traceback (most recent call last):
>>>>>   File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
>>>>>     return self.func(*args)
>>>>>   File
>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
>>>>>
>>>>> line 151, in resize
>>>>>     self.show()
>>>>>   File
>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
>>>>>
>>>>> line 155, in draw
>>>>>     tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
>>>>>   File
>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/tkagg.py", line
>>>>> 14, in blit
>>>>>     _tkagg.tkinit(id(tk), 0)
>>>>> AttributeError: 'module' object has no attribute 'tkinit'
>>>>>
>>>>>
>>>>> And an empty matplotlib window opens on my desktop.
>>>>>
>>>>>
>>>>> Should I try gtk as a backend???
>>>>>
>>>>> TIA
>>>>>
>>>>> -- Andrew
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>> -
>>>>>
>>>>> This SF.net email is sponsored by: Microsoft
>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>         
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>     
>>
>>
>>
>>   
>