[Matplotlib-users] anyone using gd and paint backends?

[Moved to the devel list from users]

On a related note, I'm curious about usage of the Gdk and Wx (non-Agg) rendering backends. They both have various shortcomings relative to Agg (no antialiasing, limited mathtext rotation, etc.). Is there a real performance or other reason to keep these maintained at this point? I don't see them as significantly easier for embedding in applications than Agg (since both GtkAgg and WxAgg spell out how to get a native image buffer from the Agg buffer without using C extensions).

Hope the question doesn't offend -- I can see their "reason to be" historically, but maybe those reasons are no longer relevant.

Cheers,
Mike

Eric Firing wrote:

···

If you are using the gd or paint backends, please speak up *now*, and tell me what the advantage is over the myriad other ways of generating png files with mpl. I would like to delete these backends *soon* unless there is some real advantage in keeping them.

Thanks.

Eric

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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

The two adbantages of GTK that I am aware of are

  -- a bit faster than GTKAgg

  -- better support over X11 because you don't have to transfer the
entire bitmap on every redraws since the native X11 commands can be
transmitted.

But these advantages may not outweigh their disadvantages
(maintenance, inertia preventing us from refactoring). We could
consider adding an svn dir w/ a bunch of experimental and/or noncore
and/or not supported backends. If the backend lookup machinery were a
bit more sophisticated (eg if 'backend : myformat' is specified, the
imported will try and 'import backend_myformat' or something like
that, thern users could use backends outside the normal install tree.
Then we could remove backends we do not want to actively maintain,
while providing a location in svn for those who want to keep using
them and providing a friendly way for them to keep using them with
mpl.

JDH

JDH

···

On 9/7/07, Michael Droettboom <mdroe@...31...> wrote:

[Moved to the devel list from users]

On a related note, I'm curious about usage of the Gdk and Wx (non-Agg)
rendering backends. They both have various shortcomings relative to Agg
(no antialiasing, limited mathtext rotation, etc.). Is there a real
performance or other reason to keep these maintained at this point? I
don't see them as significantly easier for embedding in applications
than Agg (since both GtkAgg and WxAgg spell out how to get a native
image buffer from the Agg buffer without using C extensions).

Hope the question doesn't offend -- I can see their "reason to be"
historically, but maybe those reasons are no longer relevant.

Michael Droettboom wrote:

On a related note, I'm curious about usage of the Gdk and Wx (non-Agg) rendering backends. They both have various shortcomings relative to Agg (no antialiasing, limited mathtext rotation, etc.). Is there a real performance or other reason to keep these maintained at this point?

I'm a heavy wx users, and have only used the wxAgg back-end.

However, if you are running an X application from a remote server, then the *Agg backends are much slower than the raw wx (or gtk) back ends -- I've never done it, but it has come up on this list. The reason is that it's faster to send the drawing commands over the network than the entire image buffer.

don't see them as significantly easier for embedding in applications than Agg (since both GtkAgg and WxAgg spell out how to get a native image buffer from the Agg buffer without using C extensions).

You're right -- I don't think that's an issue.

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