enable 2x (retina) display

[minrk]

works for matplotlib figures with:

InlineBackend.figure_format = 'retina'

and (embedded) Image objects with:

Image(data,...retina=True)

ref #2234

[Carreau]

Could the 2x factor be modifiable ? We're starting to see higher resolution that have bastard format that are not 2x (Chromebook pixel IIRC) .
I'm convince that their are only few users, but having a Bool would change the api in the future if we want multiple option.
If you think that unnecessary for now, that also fine with me.

[minrk]

could introduce an arbitrary scale factor, I guess.

[Carreau]

could introduce an arbitrary scale factor, I guess.

Up to you, You probably have more devices with variable resolutions around you than I do.

[ellisonbg]

I don't think we need to do the arbitrary scale factor yet. I don't have a retina screen to test, but the code looks good.

[ivanov]

we figured that we can add the arbitrary factor later, so decided to merge as is.

[chuckdries]

The command %config InlineBackend.figure_format = 'retina' appears to work well in Jupiter Notebooks but not in qtconsole. Any ideas why?

[ccordoba12]

@chuckdries, that's becauser qtconsole is not using Qt5, I think. According to Qt release notes, the first version that truly solves retina display problems is Qt 5.6 (released a couple of weeks ago :-)

[takluyver]

Qtconsole can run on PyQt5, I believe. I suspect there's something the qtconsole code needs to do to display the image at double-resolution, though.

[ccordoba12]

Yes, Qtconsole can run on PyQt5, but Anaconda (at least) is not using it. But I thought just setting retina for InlineBackend.figure_format was enough to have 2x images.

@minrk, is that not the case?

[minrk]

That's enough for the spec, but I'm not sure if the qtconsole handles it.

[wjakob]

Specifying

InlineBackend.figure_format = 'retina'

at the beginning of every notebook indeed does the job of providing images at the right resolution, but it's unfortunate that this is always necessary as High-DPI displays are fairly common nowadays.

It is possible to get a cross-platform pixel density value from the browser (javascript or CSS resolution query). To me, this seems like a much more robust and user-friendly way to do this automatically.

[dkasak]

Is there a reason this is not the default, at least for notebooks? The out-of-the-box experience for notebooks is pretty bad right now on a higher resolution screen, with both graphics and text very visibly blurry.

[Carreau]

Is there a reason this is not the default, at least for notebooks? The out-of-the-box experience for notebooks is pretty bad right now on a higherG resolution screen, with both graphics and text very visibly blurry.

Yes: Because the kernel does not know it is controlled from a notebook. And even if it is controlled from a notebook it does not mean the notebook is on hi-DPI screen.

[dkasak]

Ah, the first part explains it. As was mentioned before, it would probably be possible to query the DPI value. Would it make more sense then to implement this in Jupyter by making it send this command when the python kernel is used?

[Carreau]

You can't really do that either, as the frontend try to be as agnostic as possible WRT what language is implemented in the back end and sending that command would be an IPython specific thing. Also nothing guarantee that the kernel is connected to a single client ( which is even more true with RT collaboration comming soon) in which case "connected to Hi DPI" is not a binary choice.

…

On Jun 24, 2017 12:29, "Denis Kasak" ***@***.***> wrote: Ah, the first part explains it. As was mentioned before, it would probably be possible to query the DPI value. Would it make more sense then to implement this in Jupyter by making it send this command when the python kernel is used? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3381 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUez2sLYNa5mggrAYlKQzjSX1UHyT9Nks5sHOUDgaJpZM4AsWrs> .

[dkasak]

You can't really do that either, as the frontend try to be as agnostic as possible WRT what language is implemented in the back end and sending that command would be an IPython specific thing. Also nothing guarantee that the kernel is connected to a single client ( which is even more true with RT collaboration comming soon) in which case "connected to Hi DPI" is not a binary choice.

That sounds reasonable and I realize the frontend is maximally agnostic of the backend by design. On the other hand, this particular situation is less than ideal and seems to point to a possible deficiency in the abstraction from a usability point of view. Perhaps there is a need for a way to specify some backend-specific configuration in Jupyter?

I'm also trying to consider what a higher-by-default figure resolution would imply for lower resolution screens. I'm not too familiar with the current architecture of Jupyter, but I suppose there isn't any scaling involved so the figure would simply appear larger than usual? I'm wondering whether this is perhaps a more graceful kind of failure than displaying blurry images. Then again, if there isn't any scaling involved, I'm not sure why I even saw blur as opposed to just a very small (but sharp) figure.

I guess a first reasonable step would be to at least make the syntax for this a bit less arcane and awkward, such as was suggested in #3982. %matplotlib inline retina or %matplotlib inline svg seem much cleaner than %config InlineBackend.figure_format = 'retina'

[ellisonbg]

I do probably agree that it is time to update the default on this. I agree that kernels should be agnostic to frontends, but the current default *is* biased towards particular frontends with low resolution rendering. I don't know the numbers, but high resolution screens are extremely popular these days. I have been embarrassed multiple times showing people matplotlib on my laptop and having to explain to them why it looks bad. Defaulting to something that looks good everywhere is a safe bet in my mind. I am also +1 for making the API simpler to adjust. That way if folks have large notebooks and need the lower resolution, it is easy to set it.

…

On Sat, Jun 24, 2017 at 6:18 AM, Denis Kasak ***@***.***> wrote: You can't really do that either, as the frontend try to be as agnostic as possible WRT what language is implemented in the back end and sending that command would be an IPython specific thing. Also nothing guarantee that the kernel is connected to a single client ( which is even more true with RT collaboration comming soon) in which case "connected to Hi DPI" is not a binary choice. That sounds reasonable and I realize the frontend is maximally agnostic of the backend by design. On the other hand, it's a somewhat sad state of affairs and seems to point to a possible deficiency in the abstraction from a usability point of view. Perhaps there *is* a need for a way to specify some backend-specific configuration in Jupyter? I'm also trying to consider what a higher-by-default figure resolution would imply for lower resolution screens. I'm not too familiar with the current architecture of Jupyter, but I suppose there isn't any scaling involved so the figure would simply appear larger than usual? I'm wondering whether this is perhaps a more graceful kind of failure than displaying blurry images. Then again, if there isn't any scaling involved, I'm not sure why I even saw blur as opposed to just a very small (but sharp) figure. I guess a first reasonable step would be to at least make the syntax for this a bit less arcane and awkward, such as was suggested in #3982 <#3982>. %matplotlib inline retina or %matplotlib inline svg seem much more reasonable than %config InlineBackend.figure_format = 'retina' — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3381 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0GwCmzJsiWx6i9eyLBWg9k8j1boZks5sHQyqgaJpZM4AsWrs> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[Carreau]

I do probably agree that it is time to update the default on this. I agree
that kernels should be agnostic to frontends, but the current default is
biased towards particular frontends with low resolution rendering. I don't
know the numbers, but high resolution screens are extremely popular these
days. I have been embarrassed multiple times showing people matplotlib on
my laptop and having to explain to them why it looks bad. Defaulting to
something that looks good everywhere is a safe bet in my mind.

I am also +1 for making the API simpler to adjust. That way if folks have
large notebooks and need the lower resolution, it is easy to set it.

If/when we change, I would consider that close to breaking API so I would prefer to have it in a major version of IPython/IPykernel.

[ellisonbg]

+1

…

Sent from my iPhone

On Jun 24, 2017, at 12:44 PM, Matthias Bussonnier ***@***.***> wrote: I do probably agree that it is time to update the default on this. I agree that kernels should be agnostic to frontends, but the current default is biased towards particular frontends with low resolution rendering. I don't know the numbers, but high resolution screens are extremely popular these days. I have been embarrassed multiple times showing people matplotlib on my laptop and having to explain to them why it looks bad. Defaulting to something that looks good everywhere is a safe bet in my mind. I am also +1 for making the API simpler to adjust. That way if folks have large notebooks and need the lower resolution, it is easy to set it. If/when we change, I would consider that close to breaking API so I would prefer to have it in a major version of IPython/IPykernel. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[kencoken]

Running notebook server 5.4.0 and iPython 6.3.1, and using:

%matplotlib inline
import matplotlib
%config InlineBackend.figure_format = 'retina'
from matplotlib import pyplot as plt
plt.plot([1,2,3,4,5])

Seems to have no effect. I can set:

matplotlib.rcParams['figure.dpi'] = 144

When running matplotlib to get retina-resolution images, but these are then displayed double-size in my notebooks.

Has something changed recently to make this fix no longer function, or am I doing something stupid at my end?