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

[Fernando Perez]

On Sun, Oct 17, 2010 at 2:28 PM, Mark Voorhies <mark.voorhies at ucsf.edu> wrote:
> I tried a first pass at this (branch "pastefig" in my github repository.
> Latest commit:
> http://github.com/markvoorhies/ipython/commit/3f3d3d2f6e1f457856ce7e5481aa681fddb72a82
> )

Thanks!!!

> 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?]

It may be time to stop for a minute to think about our payloads.  The
payload system works well but we've known all along that once we have
a clearer understanding of what we need, we'd want to refine its
design.  All along something has been telling me that we should move
to a full specification of payloads with mimetype information (plus
possibly ipython-specific extra data).  Python has a mimetype library,
and if our payloads are properly mimetype-encoded, web frontends would
have little to no extra work to do, as browsers are already tooled up
to handle gracefully mimetype-tagged data that comes in.

What do people think of this approach?

> 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
> bandwidth.

That's very odd.  Brian, Min, do you know of any such restrictions in
zmq/pyzmq?  I thought that zmq would happily handle pretty much any
binary data...

> 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).

I think setting 72dpi for this (the default for low-resolution
printing) is probably OK for now.  Later we can expose this as a
user-visible parameter and even one that could be tuned at runtime.

> 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)?

I think we simply want all payloads to move to the pub socket, and for
now keep a simple design.  We need the payloads on the pub sockets so
multiple clients can process them.  Once that is working, we can
consider finer-grained filtering.  One step at a time :)

> 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.

Let's see what comes back here about the mimetype and zmq questions,
and we'll then refine it for a pull request.

Cheers,

f