How to determine if on retina

MacOSX and iOS
1

Hi, is there a definitive way of doing this? Having trouble covering all bases.

For instance, on my monitor, for the main display I get the following:
Scale: 1, Width: 3840

So this is fine.
For a client, we get:
Scale: 2, Width: 1280, on a retina display
So I assume here, I can multiple 1280*2 = 2560, so that’s retina

However, if I scale my monitor to be 1920x1080 then I get:
Scale: 2, Width: 1920 - so if I did the multiplication again here, that would come to 3840 which would register as retina even though it’s not.

So, is there a better way to determine if I’m on a retina screen or not?

thx

2

In the demoRunner/systemInfoDemo the DPI info ?

3

Client gets 144 dpi on his monitor - so do I, for both 1920 and 2560 resolution (funnily enough when running at 3840 is goes down to 72)

4

Ok, I understand, you can get the retina mode active but it seems you need to have the materiel info to know if you are on a retina display hardware.

1 Like
5

What are you using this information for?
“Retina” is an Apple marketing term, you’ll have to think in terms of resolution and scale factor to cover all bases and what this means.

3 Likes
6

I have 2 sets of assets - I want to use the hi-res assets if on a “retina” screen, i.e. an apple screen with 2560 or higher horizontal res.

7

I think for that you need to use the bounds of your Component and the scale factor of the Graphics context passed to paint to figure out what the appropriate asset is.

Remember, on desktop your app can move between windows so the resolution and scale will change and you’ll need to react to this.

1 Like
8

thanks for the suggestion - will give it a go

9

Not sure how to do this…?

10

g.getInternalContext().getPhysicalPixelScaleFactor()

6 Likes
11

Hi @leehu - I’m wondering how retina display support has worked out in practice for you.

Specifically - while it is possible to use getPhysicalPixelScaleFactor() to choose different graphics assets, I’m wondering if that has been worth the hassle. The alternate approach to retina support would be to include only one set of 2x images, and always scale them in your graphics routines.

For example, for a plug-in editor with a 600 x 300 nominal window, you would include a single background image that was 1200 x 600. Without bothering to check for the PhysicalPixelScaleFactor, you would always just use Graphics::drawImage to scale the 2x background image dimensions into the 1x logical pixel dimensions.

I guess I see the tradeoff as a little extra processor work for a lot of extra developer sanity… if there are other factors people would consider, though, I’d like to hear them.

12

Hi, that’s exactly what I ended up doing.

13

just out of curiosity. if this is a plug-in or a UI. why aren’t you (or are you) using vector-based assets?

Most graphic-designers could provide decent output that can be parsed with juce SVG parser (most of the time). so the assets won’t care much about the scaling.

14

This case for me was a client who only provided bitmap assets - I tried to get him to get his designer to produce vector assets but wasn’t happening.

15

I actually wasn’t aware that there was an SVG parser! Still fairly new to JUCE.

I see the juce_SVGParser.cpp file in the JUCE library, but its methods seem to be absent from the online documentation. I’m guessing that’s because it’s the only drawables module with a .cpp file but no header file, so no docs were generated for it…anybody know the reason for that?

16

Try this:

https://docs.juce.com/master/classDrawable.html#af1fa4fa00c6e37bcaa7a9322a81bd2ec

17

Cool, thanks!

18

In addition to the replies above, there are products that wish to be photo-realistic (plug-ins mainly) and vector graphics for those simply isn’t enough :sob:

1 Like