matplotlib-devel Mailing List for matplotlib

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.