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
> 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
> 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
> 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
> 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
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
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.
> SKA South Africa
>> 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,
>> 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.
>> 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.
>> Matplotlib-devel mailing list
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA