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
