Now that the first high-resolution displays for windows will arrive, it would be cool if there is an option to scale all windows automatically (it seems also that windows 8.1 will add something new to this, but anywhere there is a existing option in windows for ages. Control Panel -> Appearance and Personalization)
Test with 200%
VS2012 scales correctly, Juce Demo not:
[attachment=0]res.png[/attachment]
Yeah, I know, I’ve got an MS Surface and need to get this working for my own projects like tracktion.
The annoying thing is that although applying a transform to a normal component is trivial, to transform a ComponentPeer is a total nightmare, because to do so also involves faking all the monitor sizes that are returned by the Desktop class. OSX definitely had the right idea by taking care of the overall scaling at the OS level rather than leaving it up to the apps.
do it on the App-level also has one advantage: You can change the level of scaling inside the application, without changing the OS dpi-resolution.
So if one have to big thumbs for small-gui controls, it would be easy to implement a option to resize all GUI elements with one slider.
btw this would be also an useful option for android.
Yes. I already started work on this, but it’s a real PITA to implement!
I have noticed there have been improvements in this area lately. Is not JUCE fully compatible with high resolution displays (i.e. retina, etc.)?
If so, what’s the suggested method to make an application compatible both with standard and high resolution screens, both on Windows and Mac?
It’s been fine on OSX for a long time.
On Windows it’s a total PITA because the OS doesn’t help at all, and you have to actually rescale the content yourself - so I’m currently implementing a layer that allows the entire desktop (i.e. monitor sizes, desktop component coords, etc) to be rescaled dynamically to support this. As you can imagine, this is non-trivial, but I’m starting to get to the end of it.
…FYI, in doing this work it’s becoming clear that I should have used float coordinates everywhere for Components rather than ints. I chose integers back in the early 2000s because it made more sense for performance, and because all windowing systems used ints. But as soon as a component has a non-integer scaling factor, integers just become a total liability. I think there’s a lot of behind-the-scenes work still to be done on this.
thanks, works great, as it can be (because of the integer window - borders) and i appreciate the hard work!!!
but i’m not sure if it default should be turn on, because some layout may based on int-pixel based assumptions.
For example if you create a wave-form via drawVerticalLine() it might look shattered now with a scaling of 125%.
Maybe it is a good idea to add a abstract function to MainApplication, or something similar, like void shouldUseDesktopScalingNonInteger() or so, what do you think?
[quote=“chkn”]thanks, works great, as it can be (because of the integer window - borders) and i appreciate the hard work!!!
but i’m not sure if it default should be turn on, because some layout may based on int-pixel based assumptions.
For example if you create a wave-form via drawVerticalLine() it might look shattered now with a scaling of 125%.
Maybe it is a good idea to add a abstract function to MainApplication, or something similar, like void shouldUseDesktopScalingNonInteger() or so, what do you think?[/quote]
Well, figuring out a way to make vertical line waveforms work at strange scales is one of my next to-do list items.
You can set the global scale to whatever you want - just call Desktop::setGlobalScaleFactor. By default it makes sense to use what the OS asks for, but you can override it if you like.