Juce Window inside native Window

Windows
1

Hi,

I am George, software developer in Merging Technologies which develops Pyramix DAW.

We are facing an issue after investigating upgrade to Juce 8 and after spending many hours trying to solve this, we ask for some help.

The DAW is mainly implemented in MFC and we need to host juce components inside the native Windows Dialogs.

The code below is how we host a juce::Component inside the native window

image
image644×116 19.6 KB

m_jviewhost is a native window (CStatic) while m_spJView derives juce::Component. Then at the MFC resize code, we place a native toolbar at the top of the parent window, then just below the m_jviewHost which hosts the juce window

image
image707×327 39.6 KB

When the window is shown for the first, it is wrong, the content of the Juce window is offset. If you move the window it gets to be correct as shown below

image
image974×728 15 KB

The m_jviewHost is where the orange rectangle shows but nevertheless somehow it gets drawn outside its bounds. When using Spy++ we see that the (Juce) window is at its correct position, but it manages to draw outside of its boundaries. Mouse clicks are correct, meaning they work as where the window correctly is but not as where it is displayed. The drawing offset always corresponds to the caption + border size vertically and border size horizontally of the containing MFC window. Looks like a drawing cache of O/S but I maybe wrong.

We get the same problem in the window where we host VST plug-ins.

As previously said, issue has been introduced on juce 8 so any hint on what changed that could cause that would be great.

Thanks for any help.

2

I can think of two major changes:

  • The default rendering backend on Windows is now Direct2D, which replaces the old software renderer.
  • The code that handles native window borders on Windows was reworked to add support for features like “aero snap”, native drop shadows, and the new rounded-corner window decorations on Windows 11.

Your use-case sounds fairly similar to the way that JUCE plugin editors work: the host provides a native HWND, and the plugin editor renders itself inside that HWND. The code in our VST3 client wrapper looks very similar to the code that sets up your JUCE view:

component->setOpaque (true);
component->addToDesktop (desktopFlags, systemWindow);
component->setVisible (true);

Given that JUCE plugin windows display correctly in other hosts (as far as I know!) my guess is that there’s something that Pyramix is doing differently that JUCE is not accounting for. I’m not sure what that could be, though.

The following info might help to narrow down the problem:

  • Are you using a custom Windows scale factor? Do you see the same results after changing the scale factor?
  • Are you using a high-DPI compatibility mode (this can be set by right-clicking on an executable, then selecting “Properties” → “Compatibility” → “Change high DPI settings” → “Override high DPI scaling behaviour.”). This can also be controlled programmatically using the application manifest as described here. Note that JUCE’s Direct2D renderer doesn’t interoperate well with gdiScaling mode (aka “System (Enhanced)”), so I recommend avoiding this mode, and ideally leaving the High DPI scaling override completely disabled.
  • Have you tested on any other machines? Do you get the same results on other OS versions, GPU hardware, display resolutions etc.?
  • If you build one of the JUCE 8 example plugins, does it display correctly in a non-JUCE-8 version of Pyramix? I tested JUCE’s AudioPluginDemo on an evaluation copy of Pyramix 15 on Windows 11 at 100% and 200% display scale factors, and it appeared to display correctly. If you see a different result, that might suggest that the issue is dependent on some aspect of the runtime environment.

Screenshot 2025-09-08 at 17.14.06
Screenshot 2025-09-08 at 17.14.061920×1435 131 KB

Something else you could try is using git bisect to determine which JUCE commit introduced the problem. That might help us to determine whether the problem is due to the new graphics backend, or the new window handling code, or something else.

3

Thanks for your rapid reply Reuk and for taking the time to test this on our DAW.

The released version of Pyramix does not include juce 8 so no surprise you could not reproduce.

As you suggest, it must be something specific to Pyramix because I have created a simple MFC app and I could not reproduce the issue.

I tried the the other things you suggested regarding the DPI but no luck. Eventually we run out of time and we cannot spend more time on this now. So I workaround it with a “delayed” resizing of the juce window which seems to be an acceptable solution. At least for the moment.

Thanks for your help