Bug: Windows: OpenGL Rendering is broken when scaling set from the OS

Windows
1

Hi JUCErs,

My plugin has an issue with scaling on Windows (currently testing on Windows 10, 64b) - if the scaling factor of the OS is set to something larger than 1, the GUI will be rendered smaller than its window. Essentially it will be rendered in the same physical size as when scaling is 1, but within a larger window, thus leaving empty space on the bottom and the right side of the GUI. Weirdly clicking in the empty space does click on the correct place within the GUI if it were scaled to fill its window… This is observable in FL Studio and Studio One, and it is NOT observable in the Plugin Host JUCE example.

Since my graphics are not vector, the size of the Plugin Editor is fixed (for example 600x600).
Looking at the current display’s info, the scale property constantly remains 1.

I read about some solution with AffineTransform, but I haven’t found any examples on how to do that.

Any help is much appreciated.

Cheers,
Nikolay

2

Hi, you can call it as follows to scale:

component.setTransform( AffineTransform::scale( 1.5f, 1.5f ) )

However, I would recommend changing your UI to use FlexBox and have it calculate the layout of the components for you. I used to use the transform and it becomes a bit of a nightmare to manage on anything but a simple UI.

1 Like
3

Thanks for the reply.

Shure, I will likely not use as much raster graphics in the next project either. This design was too rich to be recreated vectorially and I had to either implement Photoshop in my plugin or just use the raster graphics. :slight_smile:

How do I know what the scaling factor should be?
I get scalingFactor of 1, constantly.

So I am basically saying:

  • size my window 600x600;
  • draw this 600x600 image at 0,0 with size 600x600

And the result is the image being drawn on 600x600 physical pixels within a window that is in 600x600 virtual/logical pixels (larger frame).

How do I know what value should I use for the scaling factor when it draws my image without scaling, but sizes my window with scaling? Do I get the window size somehow? I don’t understand what the reference value should be…

4

Hi, just reread your message and saw that you’re setting the OS scaling, not something within Juce. Sounds like something the Juce team will need to deal with.

5

Well, I am still grateful for your reply. Thanks.

7

I’ve made a reproducible example and I can confirm the issue is present on latest develop branch.

My machine:

  • Windows 10 64b, v1709, OS Build 16299.192
  • Display: 23", 1920x1080
  • Scaling factor (Settings->Display->Scale & Layout) 125%

The issue is only present if OpenGL rendering is used.

PluginEditor.h:

/*
  ==============================================================================

    This file was auto-generated!

    It contains the basic framework code for a JUCE plugin editor.

  ==============================================================================
*/

#pragma once

#include "../JuceLibraryCode/JuceHeader.h"
#include "PluginProcessor.h"



class CustomOpenGLRenderer :    public OpenGLRenderer
{    
    void newOpenGLContextCreated ()
    {
    }

    void renderOpenGL ()
    {
    }

    void openGLContextClosing ()
    {
    }
};


class WinscalingissuetsenkovAudioProcessorEditor  : public AudioProcessorEditor
{
public:
    WinscalingissuetsenkovAudioProcessorEditor (WinscalingissuetsenkovAudioProcessor&);
    ~WinscalingissuetsenkovAudioProcessorEditor();

    //==============================================================================
    void paint (Graphics&) override;
    void resized() override;

private:
    CustomOpenGLRenderer renderer;
    OpenGLContext renderingContext;

    WinscalingissuetsenkovAudioProcessor& processor;

    JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (WinscalingissuetsenkovAudioProcessorEditor)
};

PluginEditor.cpp:

/*
  ==============================================================================

    This file was auto-generated!

    It contains the basic framework code for a JUCE plugin editor.

  ==============================================================================
*/

#include "PluginProcessor.h"
#include "PluginEditor.h"


//==============================================================================
WinscalingissuetsenkovAudioProcessorEditor::WinscalingissuetsenkovAudioProcessorEditor (WinscalingissuetsenkovAudioProcessor& p)
    : AudioProcessorEditor (&p), processor (p)
{

    // switch to OpenGL rendering
    renderingContext.setRenderer (&renderer);
    renderingContext.setContinuousRepainting (true);
    renderingContext.setMultisamplingEnabled (true);
    renderingContext.attachTo (*this);

    setSize (600, 600);
}

WinscalingissuetsenkovAudioProcessorEditor::~WinscalingissuetsenkovAudioProcessorEditor()
{
    // shutdown OpenGL rendering
    renderingContext.detach ();
}

//==============================================================================
void WinscalingissuetsenkovAudioProcessorEditor::paint (Graphics& g)
{
    g.fillAll (Colours::red);

    g.setColour (Colours::blue);
    g.fillRect (getLocalBounds ());

    g.setColour (Colours::white);
    g.setFont (15.0f);
    g.drawFittedText ("Hello World!", getLocalBounds(), Justification::centred, 1);
}

void WinscalingissuetsenkovAudioProcessorEditor::resized()
{
}

Here is a screenshot from latest FLStudio 64b:

win-scaling-issue-tsenkov
win-scaling-issue-tsenkov.png760×787 13 KB

If I keep the software renderer, the screen is all blue and Hello world is properly scaled and centered (as expected).

1 Like
8

Anyone from the JUCE team would like to take a look?

9

@ed95 would you like to take a look into this?

10

I’m not sure if ‘like’ is the correct word when describing scaling bugs but yes, I’ve pushed a fix to develop that should be up shortly. Thanks for the report and example

EDIT: commit is here

2 Likes
11

This resolves the problem on my initial view. But when I show another component on top (changing view or opening a panel in my UI) they appear broken.

12

OK, I’ll take another look

1 Like
13

Does this commit fix the issue for you?

14

Sorry I can’t test right now, Ed. I will revisit as soon as I can.
Thanks for working on it.

15

When you do have time to test, you can also try to cherry-pick this fix, for me it works in cases where it seems the other one doesn’t.
Cheers, Yair

1 Like