Hi Ken, Thanks for the reply. On 7/31/06, Ken McIvor <[EMAIL PROTECTED]> wrote: > 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.
What's the problem with sending the "display list" or with having most of matplotlib also exist in the separate process? As long as evaluating that display list doesn't involve making extensive callbacks into user code, then it shouldn't be a problem. Having matplotlib live on both sides of the process boundary is ok in my opinion, because it can be made to work that way. But having to have the *users's* app on both sides is a problem. Or having to do so many RPC callbacks back to users' code that a single rendering becomes intolerably slow. Conceptually, in terms of the "clear line", I think maybe a special 'axes' class would get you a lot of what is needed. That would act like a proxy for 'axes' actually living in another process. Anyway, clearly matplotlib shouldn't always use remote display. If you're using for embedded graphing then that would be silly. It would be more for general interactive use and debugging purposes. > > 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?!?! ;-) Heh, well compared to C++ at least. :-) My only experience with it was with doing some very simple operations using xmlrpc. But compared with how hard that would have been for me to do in C++ I was impressed. > 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. Ok. It's good to know practically the best way to achieve "good enough" but I like to think and discuss about how to achieve "best possible", also. :-) Regards --bb ------------------------------------------------------------------------- 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
