Graphics Issues with Windows Plugin Build

[garbagelarge]

Hello all!

I’m having an issue with a build for Windows where my images are rendering very poorly and I can’t interact with modal windows. I’m not seeing anything like that with my Mac build. I am using CLion and CMake on both OSs, but I confirmed that it exhibits the same behavior with Visual Studio and the Projucer. It’s the same for standalone and VST3 in a host, and but it also crashes the host.

I’d appreciate any insight - Thanks!

[ibisum]

Have you got:

JUCE_MODAL_LOOPS_PERMITTED=1

… set properly?

Also, what version of JUCE?

[reuk]

@garbagelarge

images are rendering very poorly and I can’t interact with modal windows

It would be helpful if you could supply a bit more information:

• Which version of JUCE are you using?
• In what way is image rendering poor? Could you provide a screenshot demonstrating the issue?
• How are you creating modal windows?
• Are your modal windows (semi-) transparent? The initial release of JUCE 8 had an issue where transparent windows in plugins sometimes stopped responding to mouse clicks, but this is fixed on the develop branch.

I’d recommend against setting JUCE_MODAL_LOOPS_PERMITTED=1 unless you have a good reason (e.g. a very large project with lots of modal loops that would be time-consuming to update). Modal loops can be very problematic in plugins, and enabling this flag is likely to create new problems. Generally, functions that use modal loops internally have async alternatives that are safer for use in plugins.

I’d also suggest that in general, opening secondary windows in a plugin is a bad idea. Whenever possible, it’s better to reuse the main editor window. This can help to avoid situations where modal windows get lost behind the DAW or plugin window. AUv3 plugins on macOS also don’t support secondary windows, so it’s a good idea to plan accordingly if you want to support that format in the future.

[garbagelarge]

Thanks for the response

I have not set JUCE_MODAL_LOOPS_PERMITTED, so it defaults to 1?

I am tracking the develop branch for JUCE, so 8.0.1

[garbagelarge]

Thanks for all the help!

@reuk

• Which version of JUCE are you using?

develop branch/8.0.1

@reuk

• In what way is image rendering poor? Could you provide a screenshot demonstrating the issue?

I had a little more luck searching the forum after I posted this and it seems likely that my problem is just Windows rescaling issues and I’m sure one of the documented solutions will work for me. I have SVGs for some of my images anyhow, so maybe I’ll need to learn how to use them

@reuk

• How are you creating modal windows?

I may be using my words incorrectly - these are just components, not true windows.

For example:

    auto trialMessageWeakReference = juce::WeakReference<Component> (&trialMessage);
    auto maskWeakReference = juce::WeakReference<Component> (&mask);
    trialMessage.enterModalState (false, juce::ModalCallbackFunction::create ([trialMessageWeakReference, maskWeakReference] (int result) {
        if (trialMessageWeakReference != nullptr)
            trialMessageWeakReference->setVisible (false);
        if (maskWeakReference != nullptr)
            maskWeakReference->setVisible (false);
    }));

and then:

static void exit (const juce::Button* button)
{
if (auto* parent = button->getParentComponent())
parent->exitModalState (button->getCommandID());
}

@reuk

• Are your modal windows (semi-) transparent? The initial release of JUCE 8 had an issue where transparent windows in plugins sometimes stopped responding to mouse clicks, but this is fixed on the develop branch.

Some are and some are not, but I am on the develop branch, so should be ok.

@reuk

I’d also suggest that in general, opening secondary windows in a plugin is a bad idea. Whenever possible, it’s better to reuse the main editor window. This can help to avoid situations where modal windows get lost behind the DAW or plugin window. AUv3 plugins on macOS also don’t support secondary windows, so it’s a good idea to plan accordingly if you want to support that format in the future.

Yeah - I think I am only talking about a component in the main window as opposed to a true secondary window. These are just things like the save preset box, preferences, warnings, etc…

Thanks again!

[garbagelarge]

@garbagelarge

I had a little more luck searching the forum after I posted this and it seems likely that my problem is just Windows rescaling issues and I’m sure one of the documented solutions will work for me. I have SVGs for some of my images anyhow, so maybe I’ll need to learn how to use them

I did have some luck using the AVIR resizing algorithm from gin (thanks gin!) - it is not a perfect solution - I plan on exploring SVGs further.

@garbagelarge

I may be using my words incorrectly - these are just components, not true windows.

For example:

    auto trialMessageWeakReference = juce::WeakReference<Component> (&trialMessage);
    auto maskWeakReference = juce::WeakReference<Component> (&mask);
    trialMessage.enterModalState (false, juce::ModalCallbackFunction::create ([trialMessageWeakReference, maskWeakReference] (int result) {
        if (trialMessageWeakReference != nullptr)
            trialMessageWeakReference->setVisible (false);
        if (maskWeakReference != nullptr)
            maskWeakReference->setVisible (false);
    }));

and then:

static void exit (const juce::Button* button)
{
if (auto* parent = button->getParentComponent())
parent->exitModalState (button->getCommandID());
}

Any suggestions for things I can try for the modal component issue?

Thanks!

Ben

[reuk]

@garbagelarge

Any suggestions for things I can try for the modal component issue?

Sorry, it’s difficult to say. How are you testing whether you can interact with the modal component?

If you’re able to modify one of the demo projects to reproduce the problem, that would make it much easier for someone to debug the issue and work out what’s going wrong.