Comparison of plotting packages

Specific Domains Visualization
,
1

I want to write a small 2d physical simulation to sharpen my Julia skills and learn how to use Julia to display more than “regular plots”
I saw a post suggesting using either Makie, Plots or Javis
I don’t want to start a fan war but would appreciate a comparison of the different use cases where each of the packages shines and where it can be challenging to use

9 Likes
2

Summary of Plotting Packages

  • Plots.jl is the most used. It’s probably the most documented, used in the most tutorials, and is used in many videos.
    • Pros: Its main draw is that it has a lot of plugins to other packages through its recipes system, which means that a lot of odd things like plot(sol::ODESolution) or showing the sparsity of a BandedMatrix just works. With all of these integrations, it’s normally what I would recommend first to newcomers since they will generally get the most done with the least work. It has a backend system, so you can make it generate plots via GR (the default), Plotly (i.e. make webpages), pyplot, PGFPlots (Latex output), UnicodePlots (i.e. output plots as text). This ease of use and flexibility is what its main draw is.
    • Cons: Its downside has traditionally been its startup time, though it’s nearly a second now so that’s fine. Its main downside now is mostly that it’s not as configurable as something like Makie, and it’s not as optimized if you get up to millions of points. Its flexibility means it’s not just for standard plots but also for animations, building small graphical user interfaces, and building small apps.
  • Makie is probably the second most popular. It’s natively Julia so it’s cool in that aspect, you can see code all the way down.
    • It’s very optimized for large plots, especially with GPU acceleration via the OpenGL backend (GLMakie). It has a lot of examples these days.
    • Its downside is that it’s a bit less “first user friendly”, given that its flexibility means there’s a lot more options you’re forced to specify everywhere. It has a recipe system now but it’s fairly new and not well-integrated with most of the ecosystem, so it’s not as seamless as Plots, though by 2024 I would assume that would largely be fixed. It has the longest startup time, used to be in minutes but now it’s like 5-10 seconds.
  • AlgebraOfGraphics.jl is a grammar of graphics front-end to Makie. This essentially means it has an API that looks and acts like R’s ggplot2. Thus it has largely the same pros and cons as Makie, since it’s just calling Makie under the hood, but with the pro of being more familiar to users coming from R.
  • Gadfly is a grammar of graphics based library.
    • Pros: It’s very familiar to a ggplot2 user. Its default theme is pretty nice looking.
    • Cons: It’s a bit high on startup time, closer to Makie than Plots. Also, it’s pretty feature poor. In particular, it is missing 3D plots, animations, the ability to make interactive apps with buttons, etc. For these reasons more and more people are adopting AlgebraOfGraphics, but if you’re just doing some standard statistics it’s fine.
  • Vega and VegaLite are of the same camp as Gadfly in the focus towards “standard” statistics and data science, but using wrappers to Javascript libraries.
    • Pro: Fast startups
    • Cons Similar to Gadfly, little to no flexibility (making apps, animations, …) and integration with Julia libraries beyond Queryverse.
  • PlotlyLight is a no-frills wrapper to Plotly.
    • Pro: No startup time
    • Cons: Requires reading the Plotly docs to know how to use it and has little flexibility or integration into Julia libraries.
  • GR is a front end to a C library GR. It’s actually used as the default front-end from Plots.jl. Many more people use it from Plots.jl than directly due to the integrations and docs, but it is nice for some things on its own.
    • Pros: It’s fast, scales fairly well, has a fast startup time, has a nice GUI for investigating results, integrates well with ITerm, very flexible.
    • Cons: It’s docs are bit difficult, and it doesn’t have any integrations with Julia libraries.
  • PGFPlotsX.jl is a front-end to generate plots for Latex.
    • Pros: Fast startup, output to Latex which makes it easy to then further modify in publication documents.
    • Cons: Its interface is wonky, even if you are familiar with the pgfplots Latex package. This makes quite hard to use and teach. Very few integrations with Julia libraries (Measurements and Colors only?). Lacking flexibility in terms of animations and making apps, though it’s quite flexible in its ability to modify the plots and make weird things.
  • UnicodePlots.jl is very simple, fast startup, and plots to text. Its downside of course is that text is the only output it has.
  • Gaston.jl a front-end to gnuplot.
    • Fast startup.
    • Pretty basic, lacking flexibility and integrations with Julia packages. Requires gnuplot so limitations on where it can be installed.
  • GMT.jl is “generic mapping tools”. It has some plotting tools highlighted here.
    • Pros: Has good examples in the docs. Nice extra tools for maps.
    • Cons: Missing some standard plot types like trisurf, missing integrations with other Julia packages.
  • GNUPlot.jl uses gnuplot under the hood.
    • Pros: Instant startup, has some interesting data science integrations for things like named datasets, very complete set of plots
    • Cons: Not the most complete documentation, requires Linux with gnuplot.

tl;dr

Plots.jl is the most used for a reason. It’s very flexible, integrates with the most Julia packages so you’ll find it all throughout other docs, and it has many of the advantages of the other libraries through its backend system. Thus if you needed Latex output, use the pgfplots backend. If you needed a webpage, use the Plotly backend. Unicodeplots backend when you want text output. Or the GR default for the basics. With Julia v1.9 its startup time is much improved (and it’s like sub second on v1.10 beta), which was its major complaint before. If you’re going to use one plotting library and don’t care too much about every little detail, then Plots.jl is a good one to go with. It’s definitely not the best in any of the cases, animations are better in Makie, Latex is better in PGFPlotsX, etc., but it’s capable everywhere.

Makie.jl is catching up and may be the default in the near future. It scales well and its getting all of the niceties of Plots.jl. I wouldn’t learn it first if you’re new to Julia (right now, though that will likely change by 2024). But if you need animations or want to add custom buttons to a window (make a quick GUI-like thing), Makie is unmatched. If it makes its standard plotting interface a bit simpler, gets a few more integrations, and thus matches Plots.jl in simplicity, it may hit a “best of most worlds” soon.

Otherwise it’s a bit domain specific. If you were using Plots.jl and needed more flexibility for publication-quality plots, PGFPlotsX.jl can help. Or if you prefer grammar of graphics, AlgebraOfGraphics.jl is good. If you’re a stats person you may find Gadfly or VegaLite familiar, though I wouldn’t recommend them first because these don’t satisfy general user needs (try making a plot of an FEM output and see what I mean).

All of these are pretty good. You have a lot of options. In the end, pick the one that suits your needs best.

81 Likes
3

Thanks, @ChrisRackauckas for the thorough answer
Since I’m creating an animation, I’ll start with the Plots package (the docs seem clearer on this topics than Makie’s docs)
You didn’t mention Javis which seems to be focused on animations. Is that because you don’t recommend that package, or simply because you are less familiar with it

4

In case it is relevant for you, note that Makie allows to render “live” animations during simulations (in addition to post-treatment) as well as interactive visualization with widgets (sliders…). The learning curve may be a bit steepest than Plots.jl but the documentation and examples improved a lot recently.

[EDIT] Oops, I see that Chris already mentioned this in the Plots.jl description…

1 Like
5

Javis.jl and Luxor.jl aren’t plotting packages but instead are drawing packages. Think Java’s Processing library. Plotting packages are like “give me the array of data points and what do you want, a line graph? A bar graph?”. Drawing packages are “place a circle at (x,y) of radius r, and then…” Plotting packages are higher level APIs on some drawing packages, and I think almost all individuals would use a plotting package for scientific plots for many reasons (much less code and much easier to make sure it’s correct and uniform in presentation).

Note that Makie is essentially a drawing library with a plotting API. This is because it has the lineage of being a plotting library built in Julia, so it’s drawing features are exposed to the user as well (technically it’s a higher level drawing API over many backbends like Cairo, WebGL, etc.). This is the reason why it’s so flexible and it’s great for making animations and such. But for most people who are just making plots they can safely ignore this.

1 Like
6

@ChrisRackauckas overview covers julia-specific plotting packages nicely.
A much wider used than any julia-only package is matplotlib. It is accessible from Julia with PyPlot/PythonPlot with almost exactly the same syntax as in Python. That is often helpful: for example, absolutely lots of problems are already solved on stackoverflow, and Python solutions work in Julia with none or trivial changes only.
This might or might not be fitting your usecase…

6 Likes
7

And there is also GMT.jl that for unknown to me reason keeps being considered a non-plotting package. Aren’t these examples representative of a plotting package?

8 Likes
8

GMT is awesome. I think that the historic reason was that non-conventional syntax a couple of years ago. I see now that this is now streamlined to a “standard” Julia syntax, great work!

1 Like
9

Don’t forget Gnuplot.jl!

4 Likes
10

Yes, that has been an immense amount of work to give a plots-like syntax.

3 Likes
11

GR

I couldn’t find any docs or examples. Is it limited to VSCode or Electron?

12

I need to use a lot of plotting in my job. So, one of the first things I had to do when I migrated from Matlab to Julia was a lot of plotting. I experimented with Gadfly, Plots, PGFPlots, PGFPotsX, and PlotlyJS. Over time, I have made up my mind.

If you want to get something quick and straightforward, use Plots.jl. Its syntax is simple and intuitive, and the learning curve is fast.

If you want something like static plotting but with superior plotting quality, choose PGFPlotsX.jl (it is unbeatable under this context). If you know a little bit about LaTeX, you can do almost anything with PGFPlotsX that you may find in the Tex graphics system (PGFplots and TiKz), no matter how sophisticated your goals are. And you will find a lot there.

If you want something interactive and fancy, use PlotlyJS.jl. It is unbeatable in this context. You will have to learn the syntax of Plotly (a package that can be used in Julia, R, and Python), but it will be worth the price if interactivity is essential for your needs.

If you are looking for interactivity and reactivity, the best option is Pluto.jl+PlotlyJS.jl. @disberd made the integration of these two packages as smooth as it takes with PlutoPlotly.jl here. The output is immaculate in either active or static notebooks. Notice that if you directly use PlotlyJS (through its plotting engine PlotlyBase.jl) inside Pluto – instead of PlutoPlotly.jl – the plotting comes out immaculate in the active version of the notebooks. However, their static versions lose the original plotting formatted size (at least, as I know).

7 Likes
13

This comment is worthy of a blog post in my opinion. It needs a lot more exposure and should be documented somewhere.

4 Likes
14

Have to disagree here. Packages based on Cairo or GMT have superior plotting quality.

15

Warning: strong biased personal opinion expressed in this post:

I am surprised to hear such strong positive opinions in favor of PGFPlotsX (and to lesser extent GMT – its defaults seem better, but I got a bit confused by the list of examples). Both of them, when looking at their galleries of examples (1, 2) seem a bit underwhelming (this is obviously an extremely biased personal opinion). My main reason for saying this is around:

  • poor default color maps and color schemes (a mixture of personal opinion and some objective facts related to color perception)
  • a wide array of many different inconsistent line thicknesses for different plot elements
  • ugly serif fonts (this is probably very subjective, but it is also the most visceral for me)
  • ugly markers (especially for PGFPlotsX)

I assume (please correct me if I am wrong) that y’all like these two libraries because they have extreme customability and high-fidelity exports. But for me, matplotlib or makie already have extreme customability, and when exporting to high-dpi raster images (which I prefer over vector images for many technical reasons) they are also high fidelity. At the same time, matplotlib/makie/etc seem to have much more consistent default theming (along the lines of the 4 bullet points from above).

Could you share what in your workflow makes you prefer GMT / PGFPlotsX? (I know I am asking two different people here, I am not expecting an answer to cover both) I consider myself a plotting geek, and would love to know more about other folks’ workflow (especially for folks that have preferences drastically different than mine)

2 Likes
16

Hi Krastanov

I have a little difficulty following your comments about GMT but I’m ofc gladly to discuss specific examples and open to make changes if convinced.
And to address your bullet points, here are some explanations.

  • default color maps. Because in GMT we do lots of images and 3D views of grids that many times represent terrain models where shading illumination is a must, we decided to use the turbo color map as default. But many of the most known ones are available as well.

  • Regarding the line thickness, the default is 0.5 pt. If you saw examples with other thickness, that’s because in creating that example the default was not used but I don’t think this can be considered an inconsistency.

  • Fonts: more or less the same remark. The default is Helvetica, but the size is figure size dependent. We don’t want to use the same size for a 7 cm or a 11 m wide (the maximum) poster.

  • Markers: other than custom markers the available ones are those of the PostScript language.

And a final note, I’ve put in the same basket of figure quality GMT, CairoMakie and, Gadfly (those that create vector graphics that can latter be rasterized into high-res figures). Apologizes if I messed some.

3 Likes
17

PGFPlotsX is more like a drawing program for plots. Yes, I fully agree that some defaults in pgfplots (the LaTeX package) are ugly and some of them are downright insane (eg seemingly randomly “scaled” ticks in scientific notation). But I know that I can always customize my plots and achieve the result I want.

Beyond common and trivial plot kinds, the way I use PGFPlotsX is by writing functions that return a Plot or an Axis, utilizing the building blocks it offers. So I construct custom plots by programming in Julia, thus solving my very own 2-language problem for plots.

6 Likes
18

I think this is actually a bit of a whoosh. The font you are seeing is Computer Modern, the default LaTeX font. The point of pgfplots/PGFPlotsX is that your plots inherit the font and the various styles of your surrounding document. So you decide the font in your LaTeX document preamble.

It is absolutely the ne plus ultra of plotting quality for LaTeX documents, as it integrates perfectly. If you decide to scale the plot to \textwidth, the fonts keep the same. All your plots will have the right fonts and font sizes. You can set line widths and color maps globally in your document, various theming, etc. etc.

11 Likes
19

I find this astounding. Raster images in documents are an endless nightmare. They are huge, and they invariably cause a mess when you invariably need to tweak them. (For example, you realize they should be 0.75\textwidth instead of 0.9\textwidth, or when you want to reuse them in a two-column document with a different font.)

6 Likes
20

Thanks for the clarification! On the color map front, my comment incorrectly lumped together GMT and PGFPlotX – the GMT colormaps seem great after delving deeper in the examples. One thing that tripped me up was the plot with the rooster at the top of the list of examples – the neon green and red gave a bad first impression. I will edit my initial comment.