On Jul 24, 2006, at 9:16 PM, Bill Baxter wrote:
> I think all these problems could be fixed if the display interface
> were turned into a separate process that communicates with the Python
> program using pipes or some other IPC mechanism. I used this
> technique in a (C/C++) image debugging utility program I wrote
> (http://www.billbaxter.com/projects/imdebug) and it works quite well.
The biggest problem I see with this approach is that matplotlib has a
"display list" drawing model (as opposed to the "big matrix of
pixels" model). An example of what I mean is that when someone
resizes a {Gtk,Tk,Wx}Agg figure, the entire plot is re-rendered from
scratch to the new pixel dimensions. It could be a failure of
imagination, but I can't see how you could move the display interface
to a subprocess without moving the rest of matplotlib along with it.
I just can't see a clear line along which to separate out the "graph
display server" part.
> Has anyone given thought to making matplotlib work in such a manner?
> It would be hell to do in C or C++ I think, but with Python's
> extensive RPC libs I bet it wouldn't be so bad.
Python has extensive RPC libraries?!?! ;-)
In seriousness, RPC is an acknowledged weakness of Python's standard
library. For example, Python gives you a sockets API that is much
nicer to use than the BSD sockets API or WinSock, but which still
makes you worry about all of the platform-specific idiosyncrasies of
socket programming. It's my understanding that this is one of the
big reasons Twisted came into being.
As another example, before Python 2.4 added the "subprocess" module,
there was no portable way to spawn and communicate with
subprocesses... you'd have to worry about the shell of whatever
platform you were on mangling the commandline, you couldn't reliably
interrupt subprocesses on win32 (no os.kill() to send a SIGINT with),
etc.
The point of this long-winded email is that you probably could build
some kind of RPC system to run matplotlib remotely, but I believe it
would be an awful lot of work. In terms of manhours, my opinion is
that you'd come out ahead if you just focused on debugging your
current problems. I suspect that the matplotlib developers and
irregular contributers like myself will more able to help with that
debugging than we would be able to help with writing a display
server... but please don't think that I'm speaking for everyone!
Ken
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
