Retina Displays on MBP - any Juce changes needed?


#1

Hi all,

The new MacBook Pro has a retina display. Is it time to panic? WHAT ARE YOU GOING TO DO ABOUT THIS JULES?!?!?!?!?!?!

:mrgreen:

Honestly, I have no idea what this entails. My plugins use vector graphics, and most of them are resizable, so I doubt that I need to lose any sleep over this. Just wondering if anyone has any thoughts about what sort of changes we will need to incorporate into our OSX code.

Sean Costello


#2

I have no idea if any changes might be needed, but if anyone wants to buy me a new MBP I’ll happily test it out for you! :stuck_out_tongue:


#3

Drawing speed is a little slow on the iPad with a retina display, but positions etc. are translated correctly, so there’s probably no deal-breaking issue to run your code on a new MBP.


#4

I was going to ask about this.

It turns out that this can be tested on current HW. You just need to use QuartzDebug to enable HiDPI mode. Once you do that, you can select a HiDPI setting in the System Prefs > Display Control panel; that will simulate the retina display functionality (everything will look huge, but it shows how the software operates). This is on Lion or newer, of course.

When I do this with our JUCE based plugin using, say, AU Lab, what I see is that AU Lab window is rendered in Retina mode (e.g. the title bar, etc.), but that the JUCE content is upscaled. This test was just done without CoreGraphics rendering due to the conflict between CG in Juce and AAX. It may be that using CG rendering will have an impact; I will try that and report back – but it is not clear that CG is compatible with audio processing as currently implemented.

In any case, it would be good to be able support Juce rendering for Retina targets; this would appear to imply some translation between the NSView implementation and the component layer; I was wondering if anyone was planning on digging into that?

B.J.


#5

Well, enabling USE_COREGRAPHICS_RENDERING does not appear to have an impact on Retina support on Mac. I was hoping it might have an effect on text.

So, in answer to the subject question – yes some changes will be needed to support HiRez operation; it works without changes, but the graphics are blurry.


#6

[quote=“mhbj”]
When I do this with our JUCE based plugin using, say, AU Lab, what I see is that AU Lab window is rendered in Retina mode (e.g. the title bar, etc.), but that the JUCE content is upscaled. This test was just done without CoreGraphics rendering due to the conflict between CG in Juce and AAX. It may be that using CG rendering will have an impact; I will try that and report back – but it is not clear that CG is compatible with audio processing as currently implemented.
B.J.[/quote]

Sorry for the Off Topic, but what are the issue with AAX and CoreGraphics renderer ?

Thanks,


#7

As I understand it, when JUCE uses the CoreGraphics renderer (at least with AAX), CoreGraphics causes some sort of transactional lock between the kernel and user space, and this causes some mach message requests to the kernel to take much longer than they should (milliseconds vs. microseconds). The problem is that this occurs on threads other than the rendering thread (e.g. it happens on the processing thread). These hiccups can cause DAE errors and CPU spiking; using JUCE’s built in renderer rather than CoreGraphics makes this go away. It may well be that this also impacts plugin hosts as well, but we have not looked at that. In any case, as things stand, using JUCE’s built in renderer only uses a little more main thread CPU (when compiled for release it appears to be a negligible difference) than CG, but the system runs reliably. The only drawback I have seen is that CG does a much better job of reducing bitmap images than the JUCE renderer does (e…g scale factors < 1).


#8

You can enable high resolution support in your JUCE project by adding a custom key in your project settings:

“NSHighResolutionCapable”, boolean value, set to true.

Most JUCE things I’ve tested look very good on the rMBP once this key is added, only the tabview is upscaled and looks horrible =)


#9

Ah! Nice find. I can just add that flag to the introjucer’s generation code and it should all work nicely.

Re: the tab view, I’ll be tarting that up a bit shortly, I’ve known for a while that it needs to be sorted out.


#10

FYI: this should all be sorted out now - let me know if anything doesn’t work.


#11

Thanks Jules, tabs look beautiful now =)