Why on earth would anyone need it? - you may ask. Plots is already there: a very powerful interface that you can use with GR as back end to produce nearly any kind of plot. And if you don’t want to pay the performance overhead of using Plots, GR provides its own “matplotlib-like” interface for the most usual kinds of plots.
Well, in fact I do love how GR works on its own! I think that its balance between productivity, speed, and ease of installation and usage is excellent. Its high-level interface (coded in the module
jlgr inside GR) still shows some limitations, bugs and other issues, but I consider that many can be solved with a reasonable amount of effort, which is well deserved.
In the last few months I have made some small contributions for the easiest issues, but the more I delved into the code of
jlgr, the more I felt like making bigger changes. I’m aware that @jheinen also has plans for important changes in that module, although as he commented, they are more on the C-side than in the Julia-side of the package. On the other hand, I think that there is a lot of nice things that could be made with purely “Julian” features like multiple dispatch, meta-programming, etc. to improve the code, in a more accessible way for C-hopeless users (like me).
I couldn’t help the temptation of exploring that venue, and GRUtils is an experiment in that direction. If you know the code of GR you may find a big deal of copy-and-paste from
jlgr, but heavily restructured. Actually GRUtils does little that GR cannot already do, and the interface for the end user is nearly the same as the one provided by
jlgr. In most cases, you can use the documentation on the API of
jlgr to use GRUtils as well.
The main objective of restructuring the code that way is to make it easier to read and contribute to, fixing or extending it with new functionalities. When I started this, I also fancied that GRUtils might produce even faster plots than GR; for the time being I have the impression that both packages have about the same performance (both loading and using the package, including the time to the first plot), although I have not made a systematic benchmark, and I’m sure that there is a lot of room for improvement in that regard. I hope that the structure of the package is agreeable enough to encourage other users to extend it and improve it.
I have published GRUtils as a separate package, instead of producing pull requests to GR, because this way it is faster and easier to develop and test, without disturbing the ongoing development of GR. Whether this should stay like that, or this code might be eventually integrated in GR, I don’t still know. It may even happen that GRUtils becomes obsolete when Josef’s plans for GR progress further. In the meanwhile, I hope GRUtils to be a helpful resource to improve the experience of the community in plotting with GR.