i followed a little bit What can we do to make Julia grow fast? and (as usual) a long term issue of usability of plotting shows up. So i looked around a little bit on the actual packages, but (maybe it’s an observer problem) where do we see progress?
Plots.jl is quite active and it gets better every day thanks to some great contributors.
14 Likes
I have no doubt about that, but still Plots.jl is ‘only’ a plotting API, not a full plotting solution.
This fulfills all my need for making non-interactive publication quality plots: https://github.com/KristofferC/PGFPlotsX.jl. Only for PGFPlots fans though.
4 Likes
I’m back at working on a high level plotting interface for GLVisualize in MakiE.jl.
It’s basically rewriting Plots.jl from scratch, while reusing as much of it as possible. I’m trying to figure out what needs to be done differently to get performance, GUIs and better interactivity all while being closer to the hardware.
You can see it as a prototype for a new Plots.jl - if successful I’d like to port things back to Plots.jl to have the whole ecosystem profit from it.
Hopefully with the help of the community and the work I’ve already done for the GLVisualize backend in Plots.jl, we can quickly get to a comparable feature set - plus a lot of new interactive use cases.
I’m trying to make my development as public and documented as I can, which is also why I started by writing a documentation before actually implementing the functionality. So the documentation contains already quite a few pages without MakiE actually being usable.
So right now would be the best time to get involved or follow the process and give me feedback 
Let me know if you can already spot silly/unusable ideas in the documentation, so that I don’t waste time on implementing those!
11 Likes
Great Julia packages for plotting, but may I add something to the wishlist?
In Matlab one can save a plot (in *.fig format) and later replot, edit, and re-export it (i.e. more flexible than saving as *png, *pdf or so). I find this very useful, when the reviewer of the paper/thesis wants figures to be changed, the journal requests another file format, new data have become available and should be added etc.
Of all the backends for Plots.jl Plotly comes close to having such a “plot container”, the data structure returned by plot(…) can be saved in JLD format and later recovered, there is addtrace!, restyle!.. It would be nice to consider this also for the fast backends like GLVisualize.
Ideally plots would be storable in a data base with the possibility to search (for certain titles, trace names etc.). A “plot container” could then be designed with this in mind.
3 Likes
I think one of the most promising efforts was/is Winston.jl. It is pure Julia and thus is fully hackable. Integration with Gtk.jl works nicely.
Unfortunately the development behind this stalled a little bit.
1 Like
With PyPlot/Matplotlib you can use pickle to do this. However, I usually find it nicer to create the plots in a Jupyter notebook, so that you can re-run the notebook to re-create the plots as needed.
2 Likes
It would be nice to consider this also for the fast backends like GLVisualize.
That is indeed planned in MakiE: http://www.glvisualize.com/MakiE.jl/latest/output.html
Even nicer I guess, since it will output the exact plotting commands in a Julia file.
If I’m not forgetting anything, everything contained in a MakiE plot should also be serializable, so saving it as a JLD should also work.
You can do this with Plots.jl by plotting to the HDF5 backend: https://juliaplots.github.io/backends/#hdf5-hdf5-plots
1 Like
Isn’t Winston based on Cairo like Compose/Gadfly, basically for native Julia plot you have either Cairo (Winston and Gadfly) or openGL (GLVisualize) ?
For me Gadfly+Immerse is almost perfect for 2D, the only real issue is large images. I’m not sure if its issues are a limitation of the backend or a design issue (in which case it would make sense to try to build another implementation).
yes, winston is cairo based, but a rather small subset of cairo features is used, so changing the rendering would be managable.
so you are using a layer of indirection (saving the NB) to save your plots
Would be nice if the new framework supported plotting of time-series data in a seamless manner.
- x-axis to the micro/nanosecond resolution
- ability to zoom in.
- If you are plotting data for 10 days, say between 08:40:00 to 12:45:00, have the ability to ignore the daily/overnight gaps and stitch the time-series together.
- Multiple y-axis for the same x-axis.
Yes Winston is Cairo based, but its not clear to me if the rendering engine has to be pluggable. For 3D of course Cairo would not be suitable anymore. Don’t know how matplotlib solves this for their 3D stuff.
Well, it’s quite easy to draw 3d with Cairo, you just need to do the perspective transformation yourself and if you want to be fancy one should also do clipping etc.
That’s how I render out 3D vector graphics in Visualize.jl with Cairo.
Not sure if that’s what matplotlib does though 
sure if you do software raytracing this is of course feasible. But question is if thats fast enough
Well, I wanted to wait mentioning this until the work is more advanced but since there is such activity around this topic.
I am working on a higher level interface to the GMT.jl package. With current dev version one can do
x = linspace(0, 2pi,180); seno = sin.(x/0.2)*45;
pscoast(region="g", proj="A280/30/6c", frame="g", resolution="c", land="navy", fmt="png", first=true)
plot!(collect(x)*60, seno, lw=0.5, lc="red", fmt="png", marker="circle", markeredgecolor=0, size=0.05, markerfacecolor="cyan", show=1)
to produce
As you see what it brings new is that we can make not only Cartesian but projected plots. And since GMT is almost infinitely tunable the number of things one can is … large. Besides that, it produces vector graphics (default is PS but easy convertible to other formats) that have a highly zooming power.
Don’t know how feasible would be to make into another backend for Plots.jl or others to come.
Regarding speed, well it depends on how complex the image is. Simple case take about ~4 seconds for first plot (compiling) and the remaining are very fast.
5 Likes