I just read through all the scaling topics that seem pertinent, but I’ve run in to something in Live 10 that I don’t know who to report to. My gut feeling is that it is a JUCE problem that is specific to how Live 10 scales.
On my Windows 10 machine, I have a 4K monitor, and I’m running the native Windows scaling at 150% (as is normal in such contexts.) All is well and good. Live 10 features a HiDpi mode (finally!) and the way they do it, Desktop::getInstance().getDisplays().getMainDisplay().scale returns 1, but getMainDisplay().dpi returns 144 instead of the usual 96.
This is fine, and can be dealt with easily enough. My internal scaling has:
#if JUCE_WINDOWS
scale = display.dpi / 96;
#else normal scaling.
And then my sets for width and height multiply by scale and Bob is, in point of fact, my uncle.
The craziness starts with repaint(). The two orange filter graphs you see below are a single Component. Behind them, the waveform is drawn in the main Editor’s paint(). During development of this plugin, I’ve always called repaint() on the filter control, which in turn causes the resulting area in the main view to be repainted. Works fine. But in Live 10, in HiDpi mode, the repaint is correct in aspect ratio, but approximately 1/3 the correct area. You can see in the screenshot below where the waveform is cut off in the upper left hand quadrant. The normal mousing repaints or a resize cause a correct repaint, but any repaint called on the control from the editor only results in that bit.
If I call a repaint() on the entire editor, it repaints the correct aspect ratio but only 1/3 the size. (So a rectangle slightly taller than what you see in the screenshot.)
Anyone have any thoughts about what is occurring here? Any other devs in the Live 10 beta running a 4K monitor on Windows that can verify?
