Scaling factor

i see the refactored Desktop/Display classes, one question comes to my mind: Is there something like a application-wide scaling factor i can set, which applies automatically on all window-components via affine transform, but preserves the window bounds? So i can easy change the size of the elements of the whole GUI, without doing it on every parent component.

No, there’s nothing system-wide, you’d just need to do it to each top-level component.

I also just noticed this scale factor. I’ve just finished installing Windows 7 on my Retina Macbook Pro, and I set the DPI to 200% to cope with the resolution of 2880x1800. Most apps seem not to be DPI-aware and look blurry, because they’re stretched *2 in all directions. JUCE demo is not stretched (so it’s supposed to be DPI-aware), but is very small. So it’s after all not taking into account the DPI setting.
I just checked, and Desktop::Displays::getMainDisplay().scale is reporting 1.0, not 2.0 as it should be (since I set the DPI to 200%). The value seems to be always set to 1.0 by Desktop::Displays::findDisplays().

I think I only implemented the scale factor for OSX… Need to do some research to find out how it works in Windows.

Here’s how I did it for now:

int dpiX=96; HDC hdc = GetDC(NULL); if (hdc) { dpiX = GetDeviceCaps(hdc, LOGPIXELSX); ReleaseDC(NULL, hdc); } d.scale = double(dpiX)/96.0;

It correctly reports 2.0 here.
But how do I apply this scale factor so that my main window (and all its components) really gets scaled 2x afterwards? Is this implemented already?

1 Like

Component::setTransform should do the trick.

And what about Popups etc…, wouldn’t it be easier to have a global parameter for all components which are nested in a window…mmhh

No, that doesn’t work. I’ve tried to apply the scaling transformation on the JUCE Demo’s contentComponent (which I put into a holder of same size), and it won’t work because resize() is not aware of the transformation and thus the components are not placed correctly, and their size is wrong.

What should really happen is that when you change the DPI in windows, or just tell the app some user-defined scaling factor, the entire app, and everything in it should be stretched by that amount.

I suppose, in OSX, even with Retina displays, the scaling factor will still be 1. But on Windows, as soon as you’d change the DPI to anything different than 100%, it would go up or down, and accordingly the bounds of all components will be multiplied by that factor and that’s it.

Seems like the kind of thing that should be in LookAndFeel.

Bruce

It seems applying transforms on top-level windows has no effect, and its not allowed on content components.
So here is a simple container, which wraps a component to make it scalable. It would be much more handy if such a functionality could be build into the core window-class. (@jules)
and also to have default scale-factor which be can defined in the LookAndFeel-Class.

// original 
setContentOwned (contentComp, false);
// instead 
setContentOwned (new ScalableContainer(contentComp,3.f,true), false);

Sourcecode ScalableContainer:
https://github.com/jchkn/ckjucetools/blob/master/GuiLayout/ScalableContainer.h

[attachment=0]scaleContainer.png[/attachment]

The reason it’s not allowed with top-level windows is that if you tried to rotate or warp (or even translate) them, what would it do?

yes i know :slight_smile: (i was referring to your advice"there’s nothing system-wide, you’d just need to do it to each top-level component"

thats why i want to have only a simple scalabilitly parameter on windows (->setZoom() / ->setScaleingFactor() )
and as global default LookAndFeel::setDefaultScalingFactor() , so it can be used automatically application-wide and on things like popups/AlertBoxes etc…

Has this discussion lead to some changes in the JUCE code by now? I searched the git log, but found no references regarding this

1 Like