[IPython-dev] [QUAR] Re: Qt SVG clipping bug (it's NOT a matplotlib bug)- Qt won't fix...

Mark Voorhies mark.voorhies at ucsf.edu
Sun Oct 17 17:28:53 EDT 2010

On Thursday, October 14, 2010 12:08:55 pm Fernando Perez wrote:
> The trick will be sending to the client both the svg and the png at
> pastefig() time.  Later on the figures may have been destroyed, so
> unless we send that on the spot, the client would have no way of
> reconstructing this.

I tried a first pass at this (branch "pastefig" in my github repository.
Latest commit: 

The multi-image bundle is sent as type "multi", with data set to
a dict of "format"->data (so, currently, 
{"png" : PNG data from matplotlib,
 "svg" : SVG data from maptplotlib}
["multi" is probably not the best name choice -- any suggestions for
 something more descriptive/specific?]

Naively sending PNG data causes reply_socket.send_json(repy_msg)
in ipkernel.py to hang (clearing the eighth bit of the data fixes this,
does ZMQ require 7bit data?) -- I'm currently working around this by
base64 encoding the PNG, but this may not be the best choice wrt

> Technically it's pretty easy to do: the payload can carry multiple
> entries, the client can use the png for on-screen rendering (being
> generated by mpl's Agg backend, it's guaranteed to be our "gold
> standard" so anything on-screen should use that), and it can then use
> the 'hidden' SVG (or pdf - see below) when printing to html/pdf.

Generating the PNG from the mpl AGG backend does indeed give
nice clipping in the Qt console.  The one wrinkle is that the default
PNG images were larger than what we previously had in Qt.  Currently
working around this by requesting 70dpi PNGs from matplotlib, but
I'm not sure what the default should be (since this is a kernel-side
decision, it sets an upper limit on resolution for clients that don't
do their own re-rendering from the SVG; since the payload is broadcast,
this decision also has a bandwidth consequence for all clients).

> The cost is time/bandwidth/memory.  So this should probably be
> configurable, and even togglable during runtime.  Sending all three
> formats instead of just a png is obvioiusly more expensive, and users
> may be OK with plain pngs in some cases (slow link when doing remote
> collaboration, for example).

One question is how much of this can/should be configured in the kernel
vs. the client(s).  Are there situations where it would make sense to
supplement the main broadcast channel with a "high bandwidth" channel
for the subset of clients that want to receive, e.g., pdf data (or would the
complexity cost be too high to justify this)?

If the direction in my pastefig branch looks reasonable, let me know and
we can continue the discussion in the context of a pull request.  Otherwise,
it might be useful to have some more discussion on this thread wrt 
structuring/configuring the payload and wrapping it on the Qt side.


P.S. For James Gao's HTML frontend, handling the "multi" payload should just be
a matter of grabbing the "svg" part in notebook.js::execute(code) and handling
it like a regular svg payload.

More information about the IPython-dev mailing list