-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
enable 2x (retina) display #3381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Could the 2x factor be modifiable ? We're starting to see higher resolution that have bastard format that are not 2x (Chromebook pixel IIRC) . |
could introduce an arbitrary scale factor, I guess. |
Up to you, You probably have more devices with variable resolutions around you than I do. |
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. |
we figured that we can add the arbitrary factor later, so decided to merge as is. |
enable 2x (retina) display
The command %config InlineBackend.figure_format = 'retina' appears to work well in Jupiter Notebooks but not in qtconsole. Any ideas why? |
@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 :-) |
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. |
Yes, Qtconsole can run on PyQt5, but Anaconda (at least) is not using it. But I thought just setting @minrk, is that not the case? |
That's enough for the spec, but I'm not sure if the qtconsole handles it. |
Specifying
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. |
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. |
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. |
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 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>
.
|
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. |
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
[email protected] and [email protected]
|
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. |
+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.
|
Running notebook server 5.4.0 and iPython 6.3.1, and using:
Seems to have no effect. I can set:
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? |
works for matplotlib figures with:
and (embedded) Image objects with:
ref #2234