Menu
▾
▴
matplotlib-devel
|
From: Simon R. <sra...@gm...> - 2010-06-21 13:19:20
|
Hello, Our HTML5 based matplotlib backend is now available at: http://code.google.com/p/mplh5canvas/ There are some basic installation instructions and included examples to get going. Keep in mind that the weakest link at this stage is browser support. We recommend Chrome for the most hassle free experience. This is very much a beta release and has not seen action outside of our internal testing, so we expect some teething troubles :) Please let us know what works for you, and what doesn't, and we will try and fix things as they come up. Cheers, Simon and Ludwig |
|
From: Brian R. <bre...@he...> - 2011-06-06 18:59:49
|
Hello, I've been following the updates to mplh5canvas for some time now, since its debut at SciPy 2010. I am interested in working to extend mplh5canvas into a cloud-based web service as a thesis project. I have not found anybody whose is currently working on this path. Are there any active projects working on this? Specifically, I am referring to Michael Droettboom's comments of a possible web application and Simon Ratcliffe's comments about using Flex. If anyone is interested I would be happy to talk in person at SciPy next month. Cheers, Brian |
|
From: Michael D. <md...@st...> - 2011-06-13 13:35:52
|
On 06/06/2011 02:06 PM, Brian Refsdal wrote: > Hello, > > I've been following the updates to mplh5canvas for some time now, since > its debut at SciPy 2010. I am interested in working to extend > mplh5canvas into a cloud-based web service as a thesis project. I have > not found anybody whose is currently working on this path. Are there > any active projects working on this? Specifically, I am referring to > Michael Droettboom's comments of a possible web application and Simon > Ratcliffe's comments about using Flex. If anyone is interested I would > be happy to talk in person at SciPy next month. I did a little exploratory work with this at the Sage Days sprint in Seattle back in March. My (humble) assessment is that HTML 5 Canvas doesn't make much sense for any of the use cases I could dream up, and that in fact SVG is a more appropriate choice for interactive graphics. The browser support for each technology is fairly equivalent at this point, with IE9 finally getting on the SVG bandwagon. The main problem with Canvas (from the point of view of matplotlib) is that it doesn't support persistence, (without building such a layer on top in JavaScript), so if you want to update the figure, you have to send the whole thing over the wire each time. SVG, on the other hand, maintains a tree of objects that can be tweaked at any time (and the performance in the current generation of browsers is stunning). One could send all of the large data objects as SVG from matplotlib to the browser and using XML ids to maintain relationships between the client and the server. Then, do scale the data (in many common cases), it is just a matter of updating the affiine transform on that object, (as well as updating the ticks etc, but that's peanuts), which requires very little bandwidth. I have some hackish "proof of concept" code doing this kind of thing, but it's a long way from there to something that truly works. This all glosses over the path simplification stuff that matplotlib does -- the assumption here is that the browser would have access to *all* of the data, and there are probably practical limits on how big that data can be. I recently did a lot of cleanup to the SVG backend to pave the way for having persistent objects etc. -- though there is no client/server code at all in master at the moment. All of that is "to be written", perhaps by you if you're interested. Cheers, Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA |
|
From: Simon R. <sra...@gm...> - 2011-06-13 14:15:21
|
Hey Mike, Thanks for your informative assessment of Canvas vs SVG. Indeed it encapsulates much of the thinking and horse trading done when we decided on Canvas as a delivery technology for mplh5canvas. I particularly agree with you that sending smaller encapsulated updates is less bandwidth intensive (although not necessarily faster to re-rasterise the client display). We have also spent a lot of time tearing our hair out at the primitive drawing commands, the lack of dashed lines in particular is pretty painful. For us the plus points for Canvas came down to our perception of better future browser support, and that most of the browsers seemed to be putting a large push into Canvas performance. Coupled with the use of WebSockets, we felt an all HTML5 solution may be more universally supported in the long run. (although who can tell what the browser vendors are actually thinking :) Our initial testing showed that DOM manipulation was a surprising bottleneck in SVG animations and that, particularly as the SVG object count increased, Canvas performance (time to raster) was better. Also the rendering of the imshow inline png's was a lot quicker than the SVG equivalent in our initial testing. Obviously the vector strengths of SVG are highlighted with higher output DPI, and this is certainly an area of interest. This mail is mostly to give others a bit of background about our choice, I think it could easily have gone either way, and perhaps it should. Most of the client/server code could easily be factored out with a common API that accepts either an SVG or Canvas drawing object for display on the client side. This would give us the best of both worlds (raster and vector) in a number of situations (i.e. lower DPI / high animation rate using Canvas, high DPI with lots of interactivity using SVG etc...). Interactivity would need a tweak on the browser side (much easier to do with SVG than Canvas). As suggested, perhaps Brian Refsdal would be interested in looking at producing a more generic mplweb backend. How about an imshow hybrid, with a canvas for the bitmap and SVG axes and surrounds :) Cheers, Simon Ratcliffe / Ludwig Schwardt SKA South Africa www.ska.ac.za > My (humble) assessment is that HTML 5 Canvas doesn't make much sense for > any of the use cases I could dream up, and that in fact SVG is a more > appropriate choice for interactive graphics. The browser support for > each technology is fairly equivalent at this point, with IE9 finally > getting on the SVG bandwagon. The main problem with Canvas (from the > point of view of matplotlib) is that it doesn't support persistence, > (without building such a layer on top in JavaScript), so if you want to > update the figure, you have to send the whole thing over the wire each > time. SVG, on the other hand, maintains a tree of objects that can be > tweaked at any time (and the performance in the current generation of > browsers is stunning). One could send all of the large data objects as > SVG from matplotlib to the browser and using XML ids to maintain > relationships between the client and the server. Then, do scale the > data (in many common cases), it is just a matter of updating the affiine > transform on that object, (as well as updating the ticks etc, but that's > peanuts), which requires very little bandwidth. I have some hackish > "proof of concept" code doing this kind of thing, but it's a long way > from there to something that truly works. > > This all glosses over the path simplification stuff that matplotlib does > -- the assumption here is that the browser would have access to *all* of > the data, and there are probably practical limits on how big that data > can be. > > I recently did a lot of cleanup to the SVG backend to pave the way for > having persistent objects etc. -- though there is no client/server code > at all in master at the moment. All of that is "to be written", perhaps > by you if you're interested. > > Cheers, > Mike > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > Baltimore, Maryland, USA > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Michael D. <md...@st...> - 2011-06-13 16:51:41
|
On 06/13/2011 10:07 AM, Simon Ratcliffe wrote: > Hey Mike, > > Thanks for your informative assessment of Canvas vs SVG. Indeed it > encapsulates much of the thinking and horse trading > done when we decided on Canvas as a delivery technology for mplh5canvas. > > For us the plus points for Canvas came down to our perception of > better future browser support, and that most of the browsers seemed to > be putting > a large push into Canvas performance. Coupled with the use of > WebSockets, we felt an all HTML5 solution may be more universally > supported > in the long run. (although who can tell what the browser vendors are > actually thinking :) Yeah. I'll start implementing the "crystal ball" backend so we can answer that question ;) > Our initial testing showed that DOM manipulation was a surprising > bottleneck in SVG animations and that, particularly as the SVG object > count increased, > Canvas performance (time to raster) was better. Interesting result. I wonder if browsers differ in that respect. I've been using Firefox 4 primarily, but testing with Chrome as well, and have been nothing but impressed with SVG performance -- but I'm only doing getElementById and then tweaking attributes, not actually changing tree morphology. > Also the rendering of > the imshow inline png's was a lot quicker than the SVG equivalent in > our initial testing. Have you tried non-inline PNGs? The only need for inline PNGs is to have a self-contained SVG file. When one has a webapp server available that is no longer necessary. I suspect the encoding to/from base64 adds some overhead. > Obviously the vector strengths of SVG are highlighted with higher > output DPI, and this is certainly an area of interest. True. Of course, given that we already have a static SVG backend that works, it should be simple enough to have a "Print" button that generates SVG only when printing (much like Google Docs generates a PDF when printing). > This mail is mostly to give others a bit of background about our > choice, I think it could easily have gone either way, and perhaps it > should. Yes -- perhaps still an open question. I should probably also add: I have sort of a bias toward a smart server/dumb client approach to continue to leverage the existing matplotlib code as much as possible -- which is kind of at odds with the ideal arrangement for best interactive performance, which would be to move a bunch of logic into Javascript. I don't have anything against plotting with Javascript -- there are some great packages out there -- but then it becomes a very different beast. I think your work has that assumption behind it as well, but speaking to some folks at Sage Days, it's not always implied when people start drafting a plan to do this. Cheers, Mike > SKA South Africa > www.ska.ac.za > >> My (humble) assessment is that HTML 5 Canvas doesn't make much sense for >> any of the use cases I could dream up, and that in fact SVG is a more >> appropriate choice for interactive graphics. The browser support for >> each technology is fairly equivalent at this point, with IE9 finally >> getting on the SVG bandwagon. The main problem with Canvas (from the >> point of view of matplotlib) is that it doesn't support persistence, >> (without building such a layer on top in JavaScript), so if you want to >> update the figure, you have to send the whole thing over the wire each >> time. SVG, on the other hand, maintains a tree of objects that can be >> tweaked at any time (and the performance in the current generation of >> browsers is stunning). One could send all of the large data objects as >> SVG from matplotlib to the browser and using XML ids to maintain >> relationships between the client and the server. Then, do scale the >> data (in many common cases), it is just a matter of updating the affiine >> transform on that object, (as well as updating the ticks etc, but that's >> peanuts), which requires very little bandwidth. I have some hackish >> "proof of concept" code doing this kind of thing, but it's a long way >> from there to something that truly works. >> >> This all glosses over the path simplification stuff that matplotlib does >> -- the assumption here is that the browser would have access to *all* of >> the data, and there are probably practical limits on how big that data >> can be. >> >> I recently did a lot of cleanup to the SVG backend to pave the way for >> having persistent objects etc. -- though there is no client/server code >> at all in master at the moment. All of that is "to be written", perhaps >> by you if you're interested. >> >> Cheers, >> Mike >> >> -- >> Michael Droettboom >> Science Software Branch >> Space Telescope Science Institute >> Baltimore, Maryland, USA >> >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking. >> http://p.sf.net/sfu/ephox-dev2dev >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA |
|
From: Brian R. <bre...@he...> - 2011-06-13 18:46:48
|
On 06/13/2011 10:07 AM, Simon Ratcliffe wrote: > Hey Mike, > > Thanks for your informative assessment of Canvas vs SVG. Indeed it > encapsulates much of the thinking and horse trading > done when we decided on Canvas as a delivery technology for mplh5canvas. > > I particularly agree with you that sending smaller encapsulated > updates is less bandwidth intensive (although not necessarily faster > to re-rasterise the > client display). We have also spent a lot of time tearing our hair out > at the primitive drawing commands, the lack of dashed lines in > particular > is pretty painful. > > For us the plus points for Canvas came down to our perception of > better future browser support, and that most of the browsers seemed to > be putting > a large push into Canvas performance. Coupled with the use of > WebSockets, we felt an all HTML5 solution may be more universally > supported > in the long run. (although who can tell what the browser vendors are > actually thinking :) > > Our initial testing showed that DOM manipulation was a surprising > bottleneck in SVG animations and that, particularly as the SVG object > count increased, > Canvas performance (time to raster) was better. Also the rendering of > the imshow inline png's was a lot quicker than the SVG equivalent in > our initial testing. > Obviously the vector strengths of SVG are highlighted with higher > output DPI, and this is certainly an area of interest. > > This mail is mostly to give others a bit of background about our > choice, I think it could easily have gone either way, and perhaps it > should. > > Most of the client/server code could easily be factored out with a > common API that accepts either an SVG or Canvas drawing object for > display on the client side. > This would give us the best of both worlds (raster and vector) in a > number of situations (i.e. lower DPI / high animation rate using > Canvas, high DPI with lots of interactivity using SVG etc...). > Interactivity would need a tweak on the browser side (much easier to > do with SVG than Canvas). > > As suggested, perhaps Brian Refsdal would be interested in looking at > producing a more generic mplweb backend. Great! I am interested in developing some of these ideas. I particularly like the idea to keep the transport design independent of the payload. I am also looking to expand on the collaborative element in mplh5canvas, and one of my first thoughts is to move the server code to the cloud. This way all communication can travel over port 80 or 443 for maximum compatibility between networks/ISPs and the instance running matplotlib does not have to serve up pages (latency is a concern, have you found multiple ports to be superior for throughput?). I am also looking to reduce UI request contention with multiple users and develop a session space. Something akin to doodle or imgur where users can anonymously generate unique URLs to share. I have written some prototype code that separates the canvas backend from the web server and websocket server to test for latency issues, but I am open to new ideas. -Brian > > How about an imshow hybrid, with a canvas for the bitmap and SVG axes > and surrounds :) > > Cheers, > > Simon Ratcliffe / Ludwig Schwardt > > SKA South Africa > www.ska.ac.za > >> My (humble) assessment is that HTML 5 Canvas doesn't make much sense for >> any of the use cases I could dream up, and that in fact SVG is a more >> appropriate choice for interactive graphics. The browser support for >> each technology is fairly equivalent at this point, with IE9 finally >> getting on the SVG bandwagon. The main problem with Canvas (from the >> point of view of matplotlib) is that it doesn't support persistence, >> (without building such a layer on top in JavaScript), so if you want to >> update the figure, you have to send the whole thing over the wire each >> time. SVG, on the other hand, maintains a tree of objects that can be >> tweaked at any time (and the performance in the current generation of >> browsers is stunning). One could send all of the large data objects as >> SVG from matplotlib to the browser and using XML ids to maintain >> relationships between the client and the server. Then, do scale the >> data (in many common cases), it is just a matter of updating the affiine >> transform on that object, (as well as updating the ticks etc, but that's >> peanuts), which requires very little bandwidth. I have some hackish >> "proof of concept" code doing this kind of thing, but it's a long way >> from there to something that truly works. >> >> This all glosses over the path simplification stuff that matplotlib does >> -- the assumption here is that the browser would have access to *all* of >> the data, and there are probably practical limits on how big that data >> can be. >> >> I recently did a lot of cleanup to the SVG backend to pave the way for >> having persistent objects etc. -- though there is no client/server code >> at all in master at the moment. All of that is "to be written", perhaps >> by you if you're interested. >> >> Cheers, >> Mike >> >> -- >> Michael Droettboom >> Science Software Branch >> Space Telescope Science Institute >> Baltimore, Maryland, USA >> >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking. >> http://p.sf.net/sfu/ephox-dev2dev >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: william r. <wil...@gm...> - 2010-06-21 14:51:14
|
I just tested it and it's very cool! It works fairly quickly locally. It seems to work for Safari 5 and Chrome beta. Firefox 3.6.3 is a no show. I haven't tried Opera. What I'm really curious about is what is the latency like over the actual internet, or under higher server loads (given the round tripping). For us, I'd have to try to get it to work for firefox (I think as a cross platform browser, it's fairly common, especially on linux systems like Fedora, it's what the user is most likely to have.). Thanks for sharing this! William On Mon, Jun 21, 2010 at 9:19 AM, Simon Ratcliffe <sra...@gm...>wrote: > Hello, > > Our HTML5 based matplotlib backend is now available at: > > http://code.google.com/p/mplh5canvas/ > > There are some basic installation instructions and included examples > to get going. Keep in mind that the weakest link at this stage is > browser support. > > We recommend Chrome for the most hassle free experience. > > This is very much a beta release and has not seen action outside of > our internal testing, so we expect some teething troubles :) > > Please let us know what works for you, and what doesn't, and we will > try and fix things as they come up. > > Cheers, > > Simon and Ludwig > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Ondrej C. <on...@ce...> - 2010-07-06 23:49:59
|
On Mon, Jun 21, 2010 at 7:51 AM, william ratcliff <wil...@gm...> wrote: > I just tested it and it's very cool! It works fairly quickly locally. It > seems to work for Safari 5 and Chrome beta. Firefox 3.6.3 is a no show. I > haven't tried Opera. What I'm really curious about is what is the latency > like over the actual internet, or under higher server loads (given the round > tripping). For us, I'd have to try to get it to work for firefox (I think > as a cross platform browser, it's fairly common, especially on linux systems > like Fedora, it's what the user is most likely to have.). Thanks for > sharing this! > > William > > On Mon, Jun 21, 2010 at 9:19 AM, Simon Ratcliffe <sra...@gm...> > wrote: >> >> Hello, >> >> Our HTML5 based matplotlib backend is now available at: >> >> http://code.google.com/p/mplh5canvas/ >> >> There are some basic installation instructions and included examples >> to get going. Keep in mind that the weakest link at this stage is >> browser support. >> >> We recommend Chrome for the most hassle free experience. >> >> This is very much a beta release and has not seen action outside of >> our internal testing, so we expect some teething troubles :) >> >> Please let us know what works for you, and what doesn't, and we will >> try and fix things as they come up. This looks very exciting. I don't know how to install chrome on my rhel5 without root access (I didn't find any binary and the source build fails due to some missing dependencies) and I have FF3.6.6, but I'll try to download some development binary of FF, so that it works. Ondrej |
|
From: Michael D. <md...@st...> - 2010-07-07 13:52:12
|
On 07/06/2010 07:49 PM, Ondrej Certik wrote: > On Mon, Jun 21, 2010 at 7:51 AM, william ratcliff > <wil...@gm...> wrote: > >> I just tested it and it's very cool! It works fairly quickly locally. It >> seems to work for Safari 5 and Chrome beta. Firefox 3.6.3 is a no show. I >> haven't tried Opera. What I'm really curious about is what is the latency >> like over the actual internet, or under higher server loads (given the round >> tripping). For us, I'd have to try to get it to work for firefox (I think >> as a cross platform browser, it's fairly common, especially on linux systems >> like Fedora, it's what the user is most likely to have.). Thanks for >> sharing this! >> >> William >> >> On Mon, Jun 21, 2010 at 9:19 AM, Simon Ratcliffe<sra...@gm...> >> wrote: >> >>> Hello, >>> >>> Our HTML5 based matplotlib backend is now available at: >>> >>> http://code.google.com/p/mplh5canvas/ >>> >>> There are some basic installation instructions and included examples >>> to get going. Keep in mind that the weakest link at this stage is >>> browser support. >>> >>> We recommend Chrome for the most hassle free experience. >>> >>> This is very much a beta release and has not seen action outside of >>> our internal testing, so we expect some teething troubles :) >>> >>> Please let us know what works for you, and what doesn't, and we will >>> try and fix things as they come up. >>> > This looks very exciting. I don't know how to install chrome on my > rhel5 without root access (I didn't find any binary and the source > build fails due to some missing dependencies) and I have FF3.6.6, but > I'll try to download some development binary of FF, so that it works. > I found a CentOS tarball of Chromium here: http://code.google.com/p/chromium/wiki/LinuxChromiumPackages Which seems to work just fine on RHEL5. Just untar it and run "chrome-wrapper". You may want to read through the chrome-wrapper script first: it seems to contain some hardcoded paths specific to the packager's machine, so it's not exactly high quality -- but it seems to work well with the HTML5 backend. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA |
|
From: Michael D. <md...@st...> - 2010-07-07 13:57:29
Attachments:
version_check.diff
|
The matplotlib version check seems to fail with matplotlib 1.0.0. Would you consider applying the attached patch? Mike On 06/21/2010 09:19 AM, Simon Ratcliffe wrote: > Hello, > > Our HTML5 based matplotlib backend is now available at: > > http://code.google.com/p/mplh5canvas/ > > There are some basic installation instructions and included examples > to get going. Keep in mind that the weakest link at this stage is > browser support. > > We recommend Chrome for the most hassle free experience. > > This is very much a beta release and has not seen action outside of > our internal testing, so we expect some teething troubles :) > > Please let us know what works for you, and what doesn't, and we will > try and fix things as they come up. > > Cheers, > > Simon and Ludwig > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA |
|
From: Simon R. <sra...@gm...> - 2010-07-07 14:03:15
|
I have checked in your patch, thanks for the suggestion... matplotlib 1.0.0 seemed such a distant dream a couple of months back, which led to the simplistic version check :) Cheers, Simon On Wed, Jul 7, 2010 at 3:36 PM, Michael Droettboom <md...@st...> wrote: > The matplotlib version check seems to fail with matplotlib 1.0.0. Would you > consider applying the attached patch? > > Mike > > On 06/21/2010 09:19 AM, Simon Ratcliffe wrote: >> >> Hello, >> >> Our HTML5 based matplotlib backend is now available at: >> >> http://code.google.com/p/mplh5canvas/ >> >> There are some basic installation instructions and included examples >> to get going. Keep in mind that the weakest link at this stage is >> browser support. >> >> We recommend Chrome for the most hassle free experience. >> >> This is very much a beta release and has not seen action outside of >> our internal testing, so we expect some teething troubles :) >> >> Please let us know what works for you, and what doesn't, and we will >> try and fix things as they come up. >> >> Cheers, >> >> Simon and Ludwig >> >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > Baltimore, Maryland, USA > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
|
From: Michael D. <md...@st...> - 2010-07-07 15:48:37
Attachments:
clipping.diff
|
Finally had some time to play with this in detail. First, it's very cool, and thanks for doing all this work. I noticed a few things: The path-clipping approach that simply removes negative-valued vertices doesn't always work, particularly if a line segment begins in the negative and ends up in the visible part of the plot, the entire line segment will disappear. Instead, it would make more sense to make use of the clipping algorithm already in matplotlib (and implemented in fast C++) that will actually splice the line segments at the boundary. I've attached a patch for this. The display at the bottom that says "Cursor at: X, Y" is in pixels, not in data units. It would be great if this could display data units, though being general enough to support custom scales (eg. log) and projections (eg. polar) may be tricky without making a round-trip to the server. If I resize the plotting area (using either the "+" or "arrows" icon), the area where the mouse cursor can draw a zooming rectangle does not seem to be updated. Minor point: I seem to get a traceback when "text.usetex" is True. Thinking more broadly -- how difficult would it be to just use the plotting area part of the display, and not the plot selection and layout buttons along the top? I think a really great use case of this backend would be to embed plots in a web page, and have an interactive plot inline in the document. In that case, the extra layout features may be unnecessary. Also, (and I'm getting a bit out of my depth here as I haven't done a lot of web development), how hard would it be to integrate this inside of a WSGI-based webapp, perhaps a Django app? The standalone server this is nice for demos, but I can see this becoming very useful as part of a larger web application. Mike On 06/21/2010 09:19 AM, Simon Ratcliffe wrote: > Hello, > > Our HTML5 based matplotlib backend is now available at: > > http://code.google.com/p/mplh5canvas/ > > There are some basic installation instructions and included examples > to get going. Keep in mind that the weakest link at this stage is > browser support. > > We recommend Chrome for the most hassle free experience. > > This is very much a beta release and has not seen action outside of > our internal testing, so we expect some teething troubles :) > > Please let us know what works for you, and what doesn't, and we will > try and fix things as they come up. > > Cheers, > > Simon and Ludwig > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA |
|
From: Simon R. <sra...@gm...> - 2010-07-08 10:54:59
|
Hey Mike, > Instead, it would make more sense to make use of the clipping > algorithm already in matplotlib (and implemented in fast C++) that will > actually splice the line segments at the boundary. I've attached a patch > for this. Good call. Our main clipping issue that still needs to be resolved is for markers. This is actually a wider topic since our biggest performance handicap is drawing plots with large numbers of markers. Unlike, say SVG, there is no concept of a predefined shape that we can use in the HTML5 canvas element to create a marker once and then simply copy or reference for later markers. This is something we will hopefully investigate at some later date. > The display at the bottom that says "Cursor at: X, Y" is in pixels, not in > data units. It would be great if this could display data units, though > being general enough to support custom scales (eg. log) and projections (eg. > polar) may be tricky without making a round-trip to the server. As you mentioned, the trick is in giving the client some view on how pixels should map to data values without fetching these for each mouse movement. For simple cartesian plots this is probably pretty straightforward. It is something we need to get working for our internal use so it should get solved at some stage. > If I resize the plotting area (using either the "+" or "arrows" icon), the > area where the mouse cursor can draw a zooming rectangle does not seem to be > updated. The benefit of external users :) This was an old bug that crept back in. It has been fixed in the latest commit (along with your clipping patch). > Minor point: I seem to get a traceback when "text.usetex" is True. Fixed in latest commit so that it warns the user that tex is not currently supported. Another thing to do for the next release :) > Thinking more broadly -- how difficult would it be to just use the plotting > area part of the display, and not the plot selection and layout buttons > along the top? I think a really great use case of this backend would be to > embed plots in a web page, and have an interactive plot inline in the > document. In that case, the extra layout features may be unnecessary. There is already some sort of selector in place (you can append a number onto the base URL to select a specific layout). I think we will extend this to allow selection of individual plots with/without extra decorators. Then other pages could embed these URLs directly as iframes that contain only the canvas and associated javascript to display the plot. I imagine this would also be useful in the context of applications like Sage. > Also, (and I'm getting a bit out of my depth here as I haven't done a lot > of web development), how hard would it be to integrate this inside of a > WSGI-based webapp, perhaps a Django app? The standalone server this is nice > for demos, but I can see this becoming very useful as part of a larger web > application. Certainly possible. I imagine that as the WebSocket standard becomes more prevalent it will get integrated into existing frameworks. Once this happens then the framework can associate a specific WebSocket URL with a request that gets internally redirected to the running mplh5canvas server, making the user experience a bit more seamless. Our internal use is certainly heading along similar lines, with the plots being integrated into a number of container technologies including Flex and basic HTML pages. As these new use cases come along we can evaluate the architecture and integrate things a bit more seamlessly. Thanks again for the feedback, although we are quite familiar with mpl as users, we are pretty inexperienced with the backend side, and it helps a lot to get input from people who know the code well. Simon |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X