matplotlib-devel Mailing List for matplotlib

Just a note about the speed of blitting:

Generally speaking, blitting on a local machine is VERY fast.  However, if
you log in to a remote machine and display the window locally (remote
machine to local X server), blitting can be the slowest part of the whole
operation.  Profiling of the QtAgg backend shows the following items as the
slowest parts:

1) Convert the QImage (agg RGB) to QPixmap (display depth and resolution)
2) blitting the pixmap to the screen
3) Agg drawing calls

Of course the relative speeds here depend a lot on what's being drawn (agg
calls), how many pixels there are (converting and blitting), how fast the
network is (blitting), how close the screen is to the agg buffer in terms of
resolution and depth (RGB conversion) so timings between these components
can vary a lot.

In short: there are definitely cases where blitting the smallest part of the
image that's necessary is a big help.

Ted

> -----Original Message-----
> From: mat...@li...
> [mailto:mat...@li...] On Behalf Of
> Gregor Thalhammer
> Sent: Monday, April 14, 2008 1:03 AM
> To: Christopher Barker; mat...@li...
> Subject: Re: [matplotlib-devel] Unnecessary rerendering in wx/wxagg
> backends
> 
> Hi Christopher,
> 
> thanks for your valueable feedback. I am proceeding slowly, but
> steadily.
> >
> > > 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.
> I agree, this is currently more a workaround  for some missing
> rererenderings. It seems to me, that rendering the figure is avoided as
> much as possible. Possibly this is due to the support for the vector
> graphic backends (postscript, pdf, svg)? I guess that with these
> backends rendering means actually creating the output file, but I
> didn't
> have a look at the source code.
> >> self._need_rerender = True
> >
> > Where does this get set to True again? On a Figure.canvas.draw()
> call?
> Actually nowhere else. In the QtAgg backend, in Figure.canvas.draw this
> is set to True, and then a repaint event is triggered, but no explicit
> rerendering. I didn't get this fact from the beginning. As stated
> above,
> this command is essentially a workaround for a missing initial
> rerendering after creating the FigureCanvas.
> >
> >> 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?
> Actually, this code repaints the bounding box containing all damaged
> regions. I did it because the QtAgg backend also did it like this. If I
> quickly move another window in front of a matplotlib figure, than I can
> see I small difference.
> >> 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.
> You are right. To express it more clearly: In my changed code a
> rererendering of the bitmap is done on each figure.canvas.draw() (as
> before). In the onPaint event callback no rerendering is done except
> the
> very first it's get callad after the figure has been created (changed
> behaviour).
> >
> > > 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.
> Initially I thought this is optional and might avoid some unnecessary
> repainting. Later I discovered that it is crucial for interactive
> panning. And for 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.
> Didn't know this. The wxWidgets documentation states about Update():
> "Calling this method immediately repaints the invalidated area of the
> window..."
> 
> 
> >> 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.
> At least for my case I would say that these changes to the wx backend
> didn't break my code, they revealed mistakes in my code (I used
> Refresh() instead of figure.canvas.draw() calls to get a rerendering of
> the matplotlib figure).
> 
> >> 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??
> For GUI backends I would even expect that Figure.draw() should update
> the figure on screen. However, I don't know how this should be
> implemented for not breaking code which uses other backends.
> >> 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.
> Did I understand you correctly: This means to drop support for ancient
> versions of wx in newly added code? This makes developing much easier.
> 
> Gregor
> 
> 
> -----------------------------------------------------------------------
> --
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> 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

Hi Christopher,

thanks for your valueable feedback. I am proceeding slowly, but steadily.
>
> > 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.
I agree, this is currently more a workaround  for some missing 
rererenderings. It seems to me, that rendering the figure is avoided as 
much as possible. Possibly this is due to the support for the vector 
graphic backends (postscript, pdf, svg)? I guess that with these 
backends rendering means actually creating the output file, but I didn't 
have a look at the source code.
>> self._need_rerender = True
>
> Where does this get set to True again? On a Figure.canvas.draw() call?
Actually nowhere else. In the QtAgg backend, in Figure.canvas.draw this 
is set to True, and then a repaint event is triggered, but no explicit 
rerendering. I didn't get this fact from the beginning. As stated above, 
this command is essentially a workaround for a missing initial 
rerendering after creating the FigureCanvas.
>
>> 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?
Actually, this code repaints the bounding box containing all damaged 
regions. I did it because the QtAgg backend also did it like this. If I 
quickly move another window in front of a matplotlib figure, than I can 
see I small difference.
>> 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.
You are right. To express it more clearly: In my changed code a 
rererendering of the bitmap is done on each figure.canvas.draw() (as 
before). In the onPaint event callback no rerendering is done except the 
very first it's get callad after the figure has been created (changed 
behaviour).
>
> > 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.
Initially I thought this is optional and might avoid some unnecessary 
repainting. Later I discovered that it is crucial for interactive 
panning. And for 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.
Didn't know this. The wxWidgets documentation states about Update(): 
"Calling this method immediately repaints the invalidated area of the 
window..."


>> 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.
At least for my case I would say that these changes to the wx backend 
didn't break my code, they revealed mistakes in my code (I used 
Refresh() instead of figure.canvas.draw() calls to get a rerendering of 
the matplotlib figure).

>> 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??
For GUI backends I would even expect that Figure.draw() should update 
the figure on screen. However, I don't know how this should be 
implemented for not breaking code which uses other backends.
>> 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.
Did I understand you correctly: This means to drop support for ancient 
versions of wx in newly added code? This makes developing much easier.

Gregor

On Sun, Apr 13, 2008 at 9:37 PM, Eric Firing <ef...@ha...> wrote:
> John Hunter wrote:
>
> > On Sun, Apr 13, 2008 at 6:39 PM, Eric Firing <ef...@ha...> wrote:
> >
> > > The present NavigationToolbar2 is very nice, but I am thinking about an
> > >  improvement: adding a button that would rotate a constraint among three
> > >  possibilities, so that pan/zoom and rectangle select could be set to
> > >  affect only X, only Y, or be left unconstrained as at present.
> > >
> >
> > I assume you know that for panning and zooming, if you hold down the
> > 'x' key the pan/zoom is constrained in the horizontal direction and if
> > you hold down the 'y' key it is constrained to the vertical direction.
> >  It would not be hard to add support using these keys to the
> > zoom-to-rect.  Do you think having a toggle button adds more than
> > simply using these key presses?
> >
>
>  Aha! Evidently I *should* have known, but I *didn't* know, about the x and
> y keys.  Sounds more and more familiar now, so I'm sure I saw some reference
> to it quite a while ago.  Strangely, I did not stumble over it yesterday or
> today when looking at the code from the standpoint of making the proposed
> change.

It is mentioned in the tutorial
http://matplotlib.sourceforge.net/tutorial.html#toolbar2 and in the
"toolbar2" section if the user's guide.  There are other nifty nuggets
in there, like zoom to point in the zoom mode.

>  Adding the key support to the zoom-to-rect definitely would help.

This seems like a god piece of low hanging fruit.  Another feature
that a couple of folks have mentioned to me off list would be in an
constrained zoom to rect, to have the ylim (optionally) autoscale over
the y data in the zoomed region.

JDH

John Hunter wrote:
> On Sun, Apr 13, 2008 at 6:39 PM, Eric Firing <ef...@ha...> wrote:
>> The present NavigationToolbar2 is very nice, but I am thinking about an
>>  improvement: adding a button that would rotate a constraint among three
>>  possibilities, so that pan/zoom and rectangle select could be set to
>>  affect only X, only Y, or be left unconstrained as at present.
> 
> I assume you know that for panning and zooming, if you hold down the
> 'x' key the pan/zoom is constrained in the horizontal direction and if
> you hold down the 'y' key it is constrained to the vertical direction.
>  It would not be hard to add support using these keys to the
> zoom-to-rect.  Do you think having a toggle button adds more than
> simply using these key presses?

Aha! Evidently I *should* have known, but I *didn't* know, about the x 
and y keys.  Sounds more and more familiar now, so I'm sure I saw some 
reference to it quite a while ago.  Strangely, I did not stumble over it 
yesterday or today when looking at the code from the standpoint of 
making the proposed change.

The toggle button would make it more obvious that the constraint options 
exist, and would make the operation easier on my laptop with the 
trackpad, but it is much less tempting now that you have reminded me of 
the keys.  On the other hand, given that the basic functionality is 
already there with the keys, it would presumably be easier than I 
thought to add the button--although Darren doesn't like that interface 
design, and he may have a good point.

Adding the key support to the zoom-to-rect definitely would help.

> 
> I do think Darren's suggestion of making the toolbar more easily
> extensible and configurable is a good one.  A colleague of mine
> recently wanted to change the icons, drop a couple of buttons, and add
> a couple of new ones, and I think he ended up just pasting in the code
> for NavigationToolbar and modifying what he needed.  Not very
> attractive from a design persepcetive.

I agree entirely that it would be nice if it were easy for a user to pop 
buttons in or out of the toolbar.  I'm glad Darren is interested; it is 
not something I would be likely to pursue myself.  Too hard, with all 
the gui backends.

Eric
> 
> JDH

On Sun, Apr 13, 2008 at 6:39 PM, Eric Firing <ef...@ha...> wrote:
> The present NavigationToolbar2 is very nice, but I am thinking about an
>  improvement: adding a button that would rotate a constraint among three
>  possibilities, so that pan/zoom and rectangle select could be set to
>  affect only X, only Y, or be left unconstrained as at present.

I assume you know that for panning and zooming, if you hold down the
'x' key the pan/zoom is constrained in the horizontal direction and if
you hold down the 'y' key it is constrained to the vertical direction.
 It would not be hard to add support using these keys to the
zoom-to-rect.  Do you think having a toggle button adds more than
simply using these key presses?

I do think Darren's suggestion of making the toolbar more easily
extensible and configurable is a good one.  A colleague of mine
recently wanted to change the icons, drop a couple of buttons, and add
a couple of new ones, and I think he ended up just pasting in the code
for NavigationToolbar and modifying what he needed.  Not very
attractive from a design persepcetive.

JDH

Hi Eric,

On Sunday 13 April 2008 7:39:14 pm Eric Firing wrote:
> The present NavigationToolbar2 is very nice, but I am thinking about an
> improvement: adding a button that would rotate a constraint among three
> possibilities, so that pan/zoom and rectangle select could be set to
> affect only X, only Y, or be left unconstrained as at present.
[...]
> Although there might be more elegant ways to do it, I think the simplest
> way to get this functionality across backends would be to add a single
> button that rotates a variable among values of 'X', 'Y', and 'XY', and
> then let that variable constrain the effects of pan/zoom and
> rectangle-select.

I would prefer to not add a button to change the behavior of other buttons, 
but rather stack three buttons (XY,X,Y) for pan and zoom, perhaps selectable 
from a drop-down widget of some kind, so you can select which version of 
pan/zoom you want.

> It would be nicer, but more work, to have the 
> variable change the rubberband to a span-select in the latter case; I am
> inclined to start with the easiest implementation I can come up with.  I
> think the simple approach can be done with only a little bit of change
> in the backends.

That would be nice, maybe for a future addition.

> Comments?  Objections?
>
> This could also be done by making a NavigationToolbar3, but I think that
> even with inheritance from NavigationToolbar2, this would require more
> work.

I recently subclassed NavigationToolbar2 to add a crosshairs button. I have 
multi-dimensional data and I wanted to click on a point in an image to create 
an associated projection. I had to reimplement several of the toolbar2 
methods with minor changes to support an additional button. I wonder if we 
could come up with a toolbar that was easier to subclass without 
reimplementing so much of the machinery. I won't have time to pursue this 
until summer, just throwing it out there.

Darren