Redundant rendering
- Dominant language
- Jupyter Notebook
- Stars
- 13.3k
- Forks
- 5.8k
- Avg merge
- 6d 11h
- Merged PRs (30d)
- 7
Description
I want to report an annoyance with the way many mime types are handled currently. In the IJulia kernel we have https://github.com/JuliaLang/IJulia.jl/blob/master/src/execute_request.jl#L24-L44 - which basically renders all possible mimetypes of an object and then sends all of them to the client and the client gets to pick the best one to show. I understand that this is because there are many consumers of the Jupyter messaging protocol and they want to be allowed to pick which mime type to show but this effectively makes Gadfly plots (which support rendering to HTML, SVG and PNG/JPEG) 3 times slower and 3 times as memory intensive, although only the HTML version is finally displayed in, say, the notebook interface. The problem is worsened in Julia since the first plot actually also compiles the code required for the rendering of other mime types which is a huge overkill and slows down the first plot considerably...
A good way to handle this is probably have the client send an _ordered list of preferred mime types_ (probably as a separate message during start up) and the kernel can pick the best one that it can render to.
@jasongrout pointed out that, for archival notebooks, for example, you probably want all the mimetypes. Well yes, but I would love to have a way to speed it up if I am just using the notebook interface...
Contributor guide
Research direction
Start with the IJulia execute_request.jl section linked in the issue and review the Jupyter messaging protocol around MIME bundle selection. Determine how client preferences and archival use cases should coexist; done means a concrete, agreed protocol path that avoids unnecessary rendering for interactive clients without losing required MIME types.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia, jupyter-notebook
- Domain
- api, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100