@juliohm Does it help if you add ENV["PLOTS_TEST"] = "true", like we do in the plots tests https://github.com/JuliaPlots/Plots.jl/blob/master/test/runtests.jl#L11 ?

@daschw it does. Tests pass if I create this environment variable in runtests.jl. Could you please elaborate on what is happening?

In #1318 the image size of pngs has been increased by a factor of 6 for GR in order to produce higher quality files with savefig. This would however significantly increase the size of the PlotReferenceImages repo so @jheinen introduced the PLOTS_TEST variable. If this variable is set the dpi_factor is set to 1, as it was before. See https://github.com/JuliaPlots/Plots.jl/blob/master/src/backends/gr.jl#L560-L567

Does it mean that GR will by default create png images that are much larger than the other backends? I am trying to understand the consistency of the framework. I am guessing that as before if we do plot(size=(1000,500)) we will get the same image size regardless of the backend, correct?

No, you would get a file with 6000 Pixels x 3000 Pixels and you are right that's not consistent with the other backends and probably rather unexpected.
Maybe it's time to really tackle the DPI issue in Plots (#733, #740, #897, #960). I just don't have the expertise and time for this right now.

Thank you for your work @daschw, the time you put to Plots.jl is very valuable to the community. I hope these inconsistencies will go away with time. If not here, Makie.jl will hopefully fix them.

I still don't understand, why changing the DPI setting in Plots also changes the visual appearance. In GR you can set the display size using metric limits - for image-like displays, you will have to inquire the display units first and then use a corresponding range. All sizes in GR are device-independent: line-widths, marker sizes, text heights. For the latter, you can exactly specify the size of the character boxes. This even works in GUIs (like Qt) or if you use different displays on a single computer.

If it's really "made by design", that increasing the DPI settings will decrease character heights, marker sizes, etc, I will see how this can be implemented in the GR backend within Plots. I don't want GR to be inconsistent, but I can't change this behaviour in GR as it conforms to the GKS standard.

Thank you for the clarifications @jheinen, it is great to learn how GR is well-designed, my favorite backend. ❤️ I hope this fix you have in mind within Plots.jl is implemented soon. I've added ENV["PLOTS_TEST"] to my package for now, but many other packages out there (including my other packages) are missing this variable and will fail the tests.

Here's what I wrote in slack about the DPI and visual appearance:

FWIW I disagree with @jheinen on this, though it depends a little how you define “resolution”. Normally “resolution” is the relationship between the physical size of a plot, and the number of pixels it contains. But plots don’t have a physical size before printing them (well to be pedantic they have the size of the screen in which case resolution is usually considered 72 dpi).

The size of a plot on the screen is instead only given in pixels. So the question is: should the size, in pixels, of elements (line thickness, axis font, tick font, marker sizes etc) be constant (the way it is done in Plots, and almost any other plotting package I know) or scale as a constant fraction of the plot size (the way it is done in GR).

To understand the difference, consider the easiest way to change the size of a plot: resizing the plot window by dragging in the corner. With the newest terminal, this is now also possible in GR. Given the common constant-size-elements implementation, this will change how the plot looks, the aspect ratio, the size of the markers with respect to the plot area etc. With GR’s scaling-elements implementation, you will have the exact same plot - it will just get bigger and smaller on your screen.

Here’s why I like the constant-size-elements: it’s the easiest and most intuitive way to get the plot to look exactly as you want it to, because you can visually change the plot by interactively resizing, instead of having to change the size of axis fonts, lines etc programmatically and iteratively for every element.

Then there’s the second element - the resolution of finished plots, once you save them to a file. For printing this resolution will often need to be much larger than screen resolution, meaning that plots that look good on a screen at 72 dpi will become very small once it’s printed at 600 dpi.

So what is needed is something to increase the actual resolution without changing the appearance of the plot, but I don’t think the best way is to use the plot’s size, because of what I said above and because it will affect the aspect ratio.

Instead what I suggest is to have a resolution keyword that will change the size in pixels of all plot elements by a constant factor. That is actually more or less what the dpi keyword of Plots does now, but the problem is that it doesn’t affect the plot size in pixels, so the user has to double the dpi value while simultaneously doubling the size, and that is unintuitive to many.

Having interactive resizing, and a separate constant-scaling resolution keyword would, I think, be the most intuitive interface.

Fixed by #1561