createComponentScreenshot issue with Retina screens

I’m using JUCE 2.0.28 on my iPad 3 (with retina screen), and I noticed that when I call createComponentScreenshot(), the screenshot is made up at the lower resolution rather than the higher one - e.g. the screenshot is downsampled and blurry. I suspect that this might be related to the same bug as from before with CachedComponentImage rearing its ugly head again. Anyone know what’s going on here?

I did some playing around in createComponentScreenshot() multiplying things by Desktop::getInstance().getDisplays().getMainDisplay().scale and wasn’t sure how to resolve the problem. I tried changing this

    Image componentImage (flags.opaqueFlag ? Image::RGB : Image::ARGB, r.getWidth(), r.getHeight(), true);

to this

    Image componentImage (flags.opaqueFlag ? Image::RGB : Image::ARGB, r.getWidth()*Desktop::getInstance().getDisplays().getMainDisplay().scale, r.getHeight()*Desktop::getInstance().getDisplays().getMainDisplay().scale, true);

but the result was just an image that’s 2x as big, but in which only the upper-left quadrant is drawn to.

No, that method won’t automatically take into account the physical monitor resolution. And it would be completely wrong for it to do so! For example, if you have two physical displays, with different DPI levels, and your Component isn’t visible, then which DPI did the programmer want it to use? Or if your component is on the low-DPI screen, but you’re actually taking the image for use on your high-DPI screen…?

The createComponentScreenshot method should indeed have an extra parameter to let you specify a scale though, I’ll do that when I get a moment. (Remind me if I forget…)

Fair enough, but how does it decide in its current configuration what the actual output size of the image will be? It currently just always uses the “logical” coordinate system and then assigns one physical pixel in the output image to a logical pixel?

Would it possibly be useful to make a Graphics object itself have a scale that you can specify, at least when a Graphics object is being made from an Image? That might also solve the setBufferedToImage bug too.

It does: Graphics::addTransform()