Re: [matplotlib-devel] 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()
def _get_imagesave_wildcards(self):
'return the wildcard string for the filesave dialog'
@@ -1067,7 +1071,8 @@
self.print_figure(fname, dpi, facecolor, edgecolor)
self._printQued = []
-
+def _onEraseBackground(self, evt):
+pass
def _onPaint(self, evt):
"""
@@ -1078,12 +1083,22 @@
if not self._isRealized:
self.realize()
-# Render to the bitmap
-#self.draw(repaint=False)
+#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?
-# Update the display using a PaintDC
-self.gui_repaint(drawDC=wx.PaintDC(self))
-evt.Skip()
+def _onIdle(self, evt):
+print "OnIdle"
def _onSize(self, evt):
"""
--- Kopie von backend_wxagg.py Fri Jan 11 21:39:09 2008
+++ backend_wxagg.pySun Apr 6 11:24:27 2008
@@ -58,42 +58,28 @@
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.gui_repaint()
+self.Refresh(eraseBackground = False)
+self.Update()
def blit(self, bbox=None):
-"""
-Transfer the region of the agg buffer defined by bbox to the display.
-If bbox is None, the entire buffer is transferred.
-"""
+self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
+
if bbox is None:
-self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
-self.gui_repaint()
-return
-
-l, b, w, h = bbox.get_bounds()
-r = l + w
-t = b + h
-x = int(l)
-y = int(self.bitmap.GetHeight() - t)
-
-srcBmp = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
-srcDC = wx.MemoryDC()
-srcDC.SelectObject(srcBmp)
-
-destDC = wx.MemoryDC()
-destDC.SelectObject(self.bitmap)
-
-destDC.BeginDrawing()
-destDC.Blit(x, y, int(w), int(h), srcDC, x, y)
-destDC.EndDrawing()
-
-destDC.SelectObject(wx.NullBitmap)
-srcDC.SelectObject(wx.NullBitmap)
-self.gui_repaint()
+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?
filetypes = FigureCanvasAgg.filetypes
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 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)
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:
>
Re: [matplotlib-devel] [Matplotlib-users] Double zooming with twinx
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
Index: backend_bases.py
===
--- backend_bases.py (revision 5028)
+++ backend_bases.py (working copy)
@@ -1704,6 +1704,9 @@
return
xmin, ymin, xmax, ymax = lim
+
+if a._twin:
+continue
# zoom to rect
lastx, lasty = a.transData.inverse_xy_tup( (lastx, lasty) )
Index: axes.py
===
--- axes.py (revision 5028)
+++ axes.py (working copy)
@@ -447,6 +447,7 @@
sharex=None, # use Axes instance's xaxis info
sharey=None, # use Axes instance's yaxis info
label='',
+ twinax=False,
**kwargs
):
"""
@@ -500,6 +501,9 @@
self._mastery = False
if sharex: sharex._masterx = True
if sharey: sharey._mastery = True
+#
+self._twin = False
+if twinax: self._twin = True
self.set_label(label)
self.set_figure(fig)
@@ -5010,7 +5014,8 @@
right
"""
-ax2 = self.figure.add_axes(self.get_position(), sharex=self, frameon=False)
+ax2 = self.figure.add_axes(self.get_position(), sharex=self, frameon=False,
+twinax=True)
ax2.yaxis.tick_right()
ax2.yaxis.set_label_position('right')
self.yaxis.tick_left()
@@ -5026,7 +5031,8 @@
top
"""
-ax2 = self.figure.add_axes(self.get_position(), sharey=self, frameon=False)
+ax2 = self.figure.add_axes(self.get_position(), sharey=self, frameon=False,
+twinax=True)
ax2.xaxis.tick_top()
ax2.xaxis.set_label_position('top')
self.xaxis.tick_bottom()
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Double zooming with twinx
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
Index: backend_bases.py
===
--- backend_bases.py (revision 5029)
+++ backend_bases.py (working copy)
@@ -1710,28 +1710,34 @@
x, y = a.transData.inverse_xy_tup( (x, y) )
Xmin,Xmax=a.get_xlim()
Ymin,Ymax=a.get_ylim()
-
-if Xmin < Xmax:
-if x Xmax: xmax=Xmax
+
+if not a._twinx:
+if Xmin < Xmax:
+if x Xmax: xmax=Xmax
+else:
+if x>lastx: xmin, xmax = x, lastx
+else: xmin, xmax = lastx, x
+if xmin > Xmin: xmin=Xmin
+if xmax < Xmax: xmax=Xmax
else:
-if x>lastx: xmin, xmax = x, lastx
-else: xmin, xmax = lastx, x
-if xmin > Xmin: xmin=Xmin
-if xmax < Xmax: xmax=Xmax
+xmin, xmax = Xmin, Xmax
-if Ymin < Ymax:
-if y Ymax: ymax=Ymax
+if not a._twiny:
+if Ymin < Ymax:
+if y Ymax: ymax=Ymax
+else:
+if y>lasty: ymin, ymax = y, lasty
+else: ymin, ymax = lasty, y
+if ymin > Ymin: ymin=Ymin
+if ymax < Ymax: ymax=Ymax
else:
-if y>lasty: ymin, ymax = y, lasty
-else: ymin, ymax = lasty, y
-if ymin > Ymin: ymin=Ymin
-if ymax < Ymax: ymax=Ymax
+ymin, ymax = Ymin, Ymax
if self._button_pressed == 1:
a.set_xlim((xmin, xmax))
Index: axes.py
===
--- axes.py (revision 5029)
+++ axes.py (working copy)
@@ -447,6 +447,8 @@
sharex=None, # use Axes instance's xaxis info
sharey=None, # use Axes instance's yaxis info
label='',
+ twinx=False,
+ twiny=False,
**kwargs
):
"""
@@ -500,6 +502,11 @@
self._mastery = False
if sharex: sharex._masterx = True
if sharey: sharey._mastery = True
+#
+self._twinx = False
+self._twiny = False
+if twinx: self._twinx = True
+if twiny: self._twiny = True
self.set_label(label)
self.set_figure(fig)
@@ -5010,7 +5017,8 @@
right
"""
-ax2 = self.figure.add_axes(self.get_position(), sharex=self, frameon=False)
+ax2 = self.figure.add_axes(self.get_position(), sharex=self, frameon=False,
+twinx=True)
ax2.yaxis.tick_right()
ax2.yaxis.set_label_position('right')
self.yaxis.tick_left()
@@ -5026,7 +5034,8 @@
top
"""
-ax2 = self.figure.add_axes(self.get_position(), sharey=self, frameon=False)
+ax2 = self.figure.add_axes(self.get_position(), sharey=self, frameon=False,
+twiny=True)
ax2.xaxis.tick_top()
ax2.xaxis.set_label_position('top')
self.xaxis.tick_bottom()
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] improvements to color validation in rcsetup.py
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.0 -0400
+++ rcsetup.py 2008-04-07 12:33:06.0 -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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] improvements to color validation in rcsetup.py
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.bak2008-04-07 11:46:47.0 -0400
> +++ rcsetup.py2008-04-07 12:33:06.0 -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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] setting font weight via rc
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
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
