Unnecessary rerendering in wx/wxagg backends

Development matplotlib-devel
1

Dear developers,

I discovered that in backend_wx.py in _onPaint(), the callback function for repainting a matplotlib figure, every time a repaint is done also the bitmap is rerendered:

backend_wx.py/_onPaint():
...
# Render to the bitmap
self.draw(repaint=False)
...

This also affects the behaviour of the wxagg backend. Rerendering and therefore also repainting gets quite slow if, e.g., images are included in the figure. I can see this by simply dragging another window across the matplotlibfigure. Commenting out the rerendering I get a much smoother behaviour. I could not observe problems except that sometimes some parts of the figure are not properly repainted if the matplotlib figure is in the background (I only tested the wxagg backend). Therefore it seems that this rerendering every time a repaint is performed is not really necessary and should be avoided.

I tested this on matplotlib 0.91.2 on WinXP, Python 2.5, wx 2.8.7. I checked that in the current svn version the _onPaint() function is unchanged.

Gregor

2

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. This may be why it's
in there... perhaps some sort of checking to see if any draw has been
performed yet?

···

On Mon, Mar 31, 2008 at 7:58 AM, Gregor Thalhammer <gregor.thalhammer@...149...> wrote:

Dear developers,

I discovered that in backend_wx.py in _onPaint(), the callback function
for repainting a matplotlib figure, every time a repaint is done also
the bitmap is rerendered:

backend_wx.py/_onPaint():
...
# Render to the bitmap
self.draw(repaint=False)
...

This also affects the behaviour of the wxagg backend. Rerendering and
therefore also repainting gets quite slow if, e.g., images are included
in the figure. I can see this by simply dragging another window across
the matplotlibfigure. Commenting out the rerendering I get a much
smoother behaviour. I could not observe problems except that sometimes
some parts of the figure are not properly repainted if the matplotlib
figure is in the background (I only tested the wxagg backend). Therefore
it seems that this rerendering every time a repaint is performed is not
really necessary and should be avoided.

I tested this on matplotlib 0.91.2 on WinXP, Python 2.5, wx 2.8.7. I
checked that in the current svn version the _onPaint() function is
unchanged.

Gregor

-------------------------------------------------------------------------
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-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

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

3

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

···

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

Chris.Barker@...236...

4

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

5

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

Gregor Thalhammer

wxdiff (2.09 KB)

wxaggdiff (1.89 KB)

6

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

Chris.Barker@...236...