Update default sizes when hi-dpi PRs merge

[jkrumbiegel]

I think we should try to get #2544 and #2346 merged for the next minor release. The GLMakie PR would then need a follow-up where we add the same HTML export logic as for CairoMakie in the other PR. This would enable us to also use GLMakie images better in Pluto notebooks and websites, because they will look sharper and be sized correctly.

What both of these PRs entail for me is the need to change our default theme regarding default resolution, fontsize and other font related settings such as paddings, margins, etc. As noted by some people already, a newly correctly scaled window on a hidpi monitor is relatively large in terms of screen real estate and fonts are a little bigger than is practical for data visualizations with lots of tick labels and other elements.

The reason for the 800x600 default was that it was an o.k. compromise between GLMakie's behavior on retina Macbooks, where windows and fonts are currently pretty small, on the edge of being readable, and other systems where they looked maybe a bit too big but still usable. Also, an even smaller resolution with CairoMakie's px_per_unit=1 default would have looked really blurry. When the above PRs are merged, we'll support "logical" pixel sizes everywhere, and then it makes sense to go to something like 600x400 and a fontsize of 13 or 14.

Here's a comparison where I only used this little theme update:

th = Theme(
    resolution = (600, 450),
    fontsize = 13,
    colgap = 18,
    rowgap = 18,
)

This is the old:

And this would be the new. Maybe one has to click them here on github to see them at the correct size.

As with other changes of that nature, I think it's best to get it done rather quickly so that the ecosystem can adjust to the new defaults, rather than delay and have more and more people adopt obsolete settings.

[asinghvi17]

I definitely agree.

Has there been any consensus on what a Makie "pixel" is? DIP, pt, etc come to mind. Would it also make sense to then replace the default pt_per_unit = 0.75 with pt_per_unit = 1, since we're now using smaller font sizes? It shouldn't really affect user code, but will make the process of assigning physical dimensions somewhat easier to think about.

[jkrumbiegel]

The default makie unit would be a device independent pixel basically. Like px in css is also device independent. And because 1px == 0.75pt in CSS I think we should stick with pt_per_unit=0.75 because then the effective size of bitmaps and svgs are the same, which is very practical.

You can still switch to 1 manually if you want to make figures for papers and find it easier to reason this way.

[jmert]

For what it's worth, I'd argue for using the CSS definitions of units — 96 pixels/inch and 72 points/inch means there are 0.75 points / pixel. If unit effectively means pixel in a device-independent sense, then px_per_unit = 1 and pt_per_unit = 0.75 is "correct" combination.

Linux (at least on Gnome) effectively assumes 96 ppi (with scaling factors on top of that for HiDPI support) and as far as I understand, Windows does the same. I think OSX is different in that historically it took the approach that there were 72 pixels/inch, but the CSS definition being baked into all browsers means there's widespread precedent across platforms for the CSS definition.