[Feature] Retina resolution graphics

[szhorvat]

This is a feature request.

It would be nice to have retina-resolution graphics. I imagine that this could be turned on/off on demand, as this is simpler than detecting the necessity automatically. I imagine adding a new command to do toggle this.

To achieve this, simply Rasterize with ImageResolution -> 2*72 then generate HTML that includes the images at 50% scaling.

[szhorvat]

I implemented this for myself, but it's a hard-coded hack at the moment.

[cc-wr]

Can we just generally set ImageResolution to the resolution found in SystemInformation["Devices"]?

Is the resolution found in SystemInformation["Devices"] correct for your system?

[szhorvat]

Some thoughts:

What if there are multiple screens with different resolutions? This is typical when using a Mac laptop with an external screen. I'll check what SystemInformation["Devices"] returns in this situation tomorrow.

On Windows, the Front End does not yet support HiDPI, but browsers do. Thus it would be useful to be able to rasterize at high resolution on that platform.

[szhorvat]

I'll check what SystemInformation["Devices"] returns in this situation tomorrow.

It returns separate information for the two screens. 72 for one, 144 for the other.

[riccardodivirgilio]

What about using SVG? they provide infinite resolution on every zoom level. They should provide a much better experience and in some cases also less data transfer. For very complex graphics the size might be very big compared to PNG or JPEG, but for localhost it should be ok.

[szhorvat]

I was thinking the same: how I imagine this working is that there would be a configuration function to set the output type. It could also set the resolution.

SetJupyterOutput[Automatic] (* auto-detect the best or revert to default *)
SetJupyterOutput["Raster", "PixelRatio" -> 2] (* retina with 2x scaling *)
SetJupyterOutput["SVG"]

Maybe it would be even better to control this using Jupyter "magic commands" (I'm not experienced with this).

The situation is not simple though because not every format is suitable for every output.

Currently, Manipulate is output as an animated PNG. I would keep this even for SVG output.

I would also keep using raster graphics for 3D graphics, even with SVG.

SVG does not always provide accurate output, and I would not want this to be forced on me as a default.

The 2x scaled retina option also has problems: tick marks don't scale properly when increasing the resolution. They would look smaller (shorter).

Another good output format is rotatable 3D graphics, but this only makes sense for 3D.

Thinking about all these points: perhaps it's not such a good idea to have such a simplified interface for setting the output ...

[cc-wr]

Personally, I am not too hot about adding SVG, or some complicated command system, design-wise.

My inclination is to just check SystemInformation["Devices"], and if we see a higher resolution than 72 there, we set some symbol, like $JupyterNotebookDPI or whatever, to that higher resolution, and use it.

However, if WolframLanguageForJupyter is eventually being used from Jupyter over a network or something, the user can still manually set $JupyterNotebookDPI.

[kenkangxgwe]

Hi @cc-wr , could you elaborate on why you do not recommend SVG? And maartenbreddels/ipyvolume might be a good resource for 3D plots

[cc-wr]

Hi @cc-wr , could you elaborate on why you do not recommend SVG?

@kenkangxgwe, basically for the reasons @szhorvat mentioned. Also, my understanding is that exporting to SVG is just going to involve sporadic rasterization of the result anyway.

However, I do understand that the potential for dynamic resizing of some results in a Jupyter notebook would be a nice Front-End-like feature to have.

[cc-wr]

Should any additional discussion occur here?

If not, I will just create a pull request for my suggestion, and open it up for voting.

[stepelu]

I implemented this for myself, but it's a hard-coded hack at the moment.

@szhorvat, could you please share the hard-coded hack?