Backends status on transforms branch

Development matplotlib-devel
1

The following drawing backends are functional on the transforms branch:

  Agg
  Ps
  Pdf *
  Svg
  Cairo *

* These could still use some optimizations to draw_markers and/or draw_path_collection.

Now onto the "problem" ones. I had asked on the mailing list a while back about the current usefulness of the Gdk and Wx backends, and the one advantage cited was that they are faster when running in a remote X session (a valid point for some uses). I can confirm that this is the case -- for a completely non-controlled experiment, I ran a remote X11 session over our network here. I get (on simple_plot_fps.py):

Gtk: 38.44 fps
GtkAgg: 1.87 fps
Wx: 19.37 fps
WxAgg: 1.83 fps

Running locally, I get:

Gtk: 49.39 fps
GtkAgg: 27.15 fps
Wx: 19.40 fps
WxAgg: 26.04 fps

Interestingly, WxAgg is faster than Wx when running locally.

What makes updating these backends on the branch difficult? The fundamental drawing operation on the branch is compound polycurves (i.e. one or more separate polylines with possible bezier curve segments).

Gdk doesn't support polycurves natively. We could convert our polycurves to polygons (by approximating the bezier curves) on the fly and send that. That shouldn't be a major slow down in the case where there aren't in fact any curves, but it would mean writing some extension code etc.

Wx supports polycurves in its new wxGraphicsContext API (but not the wxDC API that mpl uses now). This means a fairly complete rewrite of the wx backend, that would likely affect embedders as well (since you can no longer draw to an in-memory buffer, but only a true wxClientDC). wxGraphicsContext is built on top of GDI+, Quartz or Cairo depending on platform -- therefore it's not a given that it will perform well over remote X-Windows, either.

So, we need to look at the pros/cons of continuing to support these legacy APIs going forward.

Lastly, what is the status of the EMF backend? Is anyone relying on it and/or willing to look into updating it?

Cheers,
Mike

···

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

2

IMHO a gtk and a wx back end are very important for embedding MPL in
applications. I am sure you have a replacement proposition, but I fail to
see in your list of back-end what it would be.

Cheers,

Ga�l

···

On Thu, Nov 08, 2007 at 11:23:54AM -0500, Michael Droettboom wrote:

So, we need to look at the pros/cons of continuing to support these
legacy APIs going forward.

3

Gael Varoquaux wrote:

···

On Thu, Nov 08, 2007 at 11:23:54AM -0500, Michael Droettboom wrote:

So, we need to look at the pros/cons of continuing to support these
legacy APIs going forward.

IMHO a gtk and a wx back end are very important for embedding MPL in
applications. I am sure you have a replacement proposition, but I fail to
see in your list of back-end what it would be.

I'm talking specifically about the gdk and wx drawing backends, not the GUI backends. Gtk and Wx applications that embed MPL can still use Agg (or Cairo with Gtk) for rendering.

Cheers,
Mike

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

4

Michael Droettboom wrote:

Gael Varoquaux wrote:

So, we need to look at the pros/cons of continuing to support these
legacy APIs going forward.

IMHO a gtk and a wx back end are very important for embedding MPL in
applications. I am sure you have a replacement proposition, but I fail to
see in your list of back-end what it would be.

I'm talking specifically about the gdk and wx drawing backends, not the GUI backends. Gtk and Wx applications that embed MPL can still use Agg (or Cairo with Gtk) for rendering.

Can Cairo handle the remote-X use case?

Eric

···

On Thu, Nov 08, 2007 at 11:23:54AM -0500, Michael Droettboom wrote:

5

Michael Droettboom wrote:

Wx supports polycurves in its new wxGraphicsContext API (but not the wxDC API that mpl uses now). This means a fairly complete rewrite of the wx backend,

not necessarily. You can create a GraphicsContext from a wx.DC, you may be able to just add that step for drawing polycurves.

since you can no longer draw to an in-memory buffer, but only a true wxClientDC).

you can create a GraphicsContext from a wxMemeoryDC, so yes, you can draw to a buffer.

I haev no idea what the impact on performance would be, but in general, GraphicsContext is slower than DC.

So, we need to look at the pros/cons of continuing to support these legacy APIs going forward.

yup. I know I never need a non-agg wx, but then I can see why folks running remote X severs would want it.

I wonder if there is another way to speed that up with Agg -- can you compress the bitmap data to pass it to the Xserver? is that happening already?

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

6

I'm not aware of any obvious method for enabling compression in remote X11 connections. Using the NX remote desktop system might be faster:

  http://www.nomachine.com

Ken

···

On Nov 8, 2007, at 12:17 PM, Christopher Barker wrote:

I wonder if there is another way to speed that up with Agg -- can you
compress the bitmap data to pass it to the Xserver? is that happening
already?

7

Christopher Barker wrote:

Michael Droettboom wrote:

Wx supports polycurves in its new wxGraphicsContext API (but not the wxDC API that mpl uses now). This means a fairly complete rewrite of the wx backend,

not necessarily. You can create a GraphicsContext from a wx.DC, you may be able to just add that step for drawing polycurves.

since you can no longer draw to an in-memory buffer, but only a true wxClientDC).

you can create a GraphicsContext from a wxMemeoryDC, so yes, you can draw to a buffer.

I'm having trouble just getting a wxPython to compile with wxGraphicsContext support (perhaps another argument against using it...)

I was basing this determination on the wx documentation which clearly states one can only create a wxGraphicsContext from a wxWindowDC. wxMemoryDC inherits from wxDC, not wxWindowDC. I'd be certainly happy to find out that the documentation is incorrect on this point, as it would certainly make the implementation easier.

I haev no idea what the impact on performance would be, but in general, GraphicsContext is slower than DC.

Particularly, if it works as it appears to by rendering to a Cairo buffer first.

So, we need to look at the pros/cons of continuing to support these legacy APIs going forward.

yup. I know I never need a non-agg wx, but then I can see why folks running remote X severs would want it.

I wonder if there is another way to speed that up with Agg -- can you compress the bitmap data to pass it to the Xserver? is that happening already?

You can compress the ssh connection over which X11 tunnels with the -C
commandline flag. But whether that makes things faster or slower depends on the compressability of the data itself, and the relative speeds of the processor vs. network link, of course.

Cheers,
Mike

···

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

8

I've got some more benchmarks for the WX and WXAgg backends in trunk. It looks like using ssh with compression or the NX remote desktop both substantially improve performance. I don't know why WXAgg consistently outperforms WX for me, but my guess is that the difference involves Apple's X server.

X11 Remote
  WX: 0.96 fps
  WXAgg: 1.93 fps

X11 Remote w/compression
  WX: 3.93 fps
  WXAgg: 6.43 fps

NX
  WX: 7.39 fps
  WXAgg: 10.83 fps

Local
  WX: 11.91 fps
  WXAgg: 19.16 fps

Ken

···

On Nov 8, 2007, at 10:23 AM, Michael Droettboom wrote:

So, we need to look at the pros/cons of continuing to support these
legacy APIs going forward.

9

Michael Droettboom wrote:

Christopher Barker wrote:

Michael Droettboom wrote:

Wx supports polycurves in its new wxGraphicsContext API (but not the wxDC API that mpl uses now). This means a fairly complete rewrite of the wx backend,

not necessarily. You can create a GraphicsContext from a wx.DC, you may be able to just add that step for drawing polycurves.

since you can no longer draw to an in-memory buffer, but only a true wxClientDC).

you can create a GraphicsContext from a wxMemeoryDC, so yes, you can draw to a buffer.

I'm having trouble just getting a wxPython to compile with wxGraphicsContext support (perhaps another argument against using it...)

I was basing this determination on the wx documentation which clearly states one can only create a wxGraphicsContext from a wxWindowDC. wxMemoryDC inherits from wxDC, not wxWindowDC. I'd be certainly happy to find out that the documentation is incorrect on this point, as it would certainly make the implementation easier.

I did finally get this to work -- thanks for the tip that you can use a wxGraphicsContext on a wxMemoryDC.

I haev no idea what the impact on performance would be, but in general, GraphicsContext is slower than DC.

Particularly, if it works as it appears to by rendering to a Cairo buffer first.

It's really bad, actually. It's entirely possible that I'm doing things suboptimally, of course. If someone with more wx.GraphicsContext experience were to look at backend_wx.py on the branch, I'd appreciate it.

I particularly wonder if drawing directly to a wx.Window would perform better over the network than to a wx.MemoryDC and then blitting that to the window (as both trunk and branch do now). Clipping rectangles have a major impact also. I did optimize the code so that the clipping state changes as infrequently as possible (rather than with each drawing operation), but it still has a huge impact. I suspect that wx.GraphicsContext treats all clips as clipping paths, rather than the more efficient clipping rectangles when it can.

These benchmarks are on the branch on a RHEL4 box.

Local:
WxAgg: 27.5 fps
Wx: 1.8 fps
Wx: 16.8 fps (without clipping)

Network (X11 with compression):
WxAgg: 2.0 fps
Wx: 1.7 fps
Wx: 2.0 fps (without clipping)

Windows and Mac may perform quite differently, given that they use completely different rendering code.

Unless some "trick" can be found to make this better, it's hard to recommend Wx over WxAgg on the branch.

Cheers,
Mike

···

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