Wrong globalScaleFactor factor returned in OSX plugin paint() method

1

I believe I found a major bug in the CoreGraphicsContext slowing down some drawing in plugins on OSX unnecessarily. It’s all about getPhysicalPixelScaleFactor();

This is on OSX 10.11.6 on a Retina Macbook Pro using the latest JUCE dev tip.

If I add

    DBG("scale: " << g.getInternalContext().getPhysicalPixelScaleFactor());

To the paint method of an empty standalone application I get the correct value 2.

If I add the same line to the Juce Demo Plugin editor’s paint method and build the AU version, the call returns 4.

My plugins use some cached components to speed up drawing, but now the bitmaps used for caching are scaled by 4 in x and y direction which makes things extremely slow. I think the value is also used to determine Path tesselation, affecting many drawing operations.

The problem seems to come from the targetScale member in the CoreGraphicsContext which is 2 in this case. Then the affine transform from CoreGraphics results in multiplying this by 2 again.

float CoreGraphicsContext::getPhysicalPixelScaleFactor()
{
    const CGAffineTransform t = CGContextGetCTM (context);
    return targetScale * (float) (juce_hypot (t.a, t.c) + juce_hypot (t.b, t.d)) / 2.0f;
}
2

targetScale is 2.0 in both cases, but for the AU plugin, the CGAffineTransform for some reason is scaled by 2 as well while it’s just an identity transform in the standalone application.

3

You didn’t say which host this is, but it sounds like it might be something to do with the new VST scaling factor stuff. We’ve a fix for that which we’ll push soon, but if that doesn’t help, please give us more info about the host.

4

OK should be fixed on develop now with commit c0f6918.

5

Sorry about forgetting about the host. The problem came up in AULab running in 64 bit mode.

I tested some other hosts, and so far all of them seem fine:

Logic Pro X
Mainstage
Ableton Live

6

Thanks for the fix, but I don’t think it’s related to this issue, the VST/VST3 wrapper code isn’t even compiled when I test the AU version.

The more hosts I test, the more this seems to be an AU Lab issue. So far I haven’t found any other host with the issue. I’ll let you know if I find another one.

Maybe this issue has always been there in AU Lab. On the other hand, it should use the most compatible AU hosting implementation as it’s done by the CoreAudio team.

7

The weird thing is that drawing is correct scale-wise. There seems to be some discrepancy between context transformations when drawing and when calculating the physicalPixelScaleFactor in that method.

8

It may just be AUlab messing about with the scale of its GUI… If that really is the only host where this happens then I don’t think it’s worth us spending time trying to work around it.

9

I agree. I will test more hosts next week.