BR: DocumentWindow broken in VST3 when transparent since JUCE 8

pstitt01 · June 20, 2024, 10:43am

DocumentWindow stops capturing mouse clicks after being resized when it is in a PluginEditor on Windows. The problem is not present when compiling as a Standalone but is when in a VST3. Everything works fine in JUCE 7.

Steps to reproduce:

Start a new plugin project.
Add a juce::DocumentWindow to the Editor.
Use the constructor below.
Compile and open the VST3.
Resize the window by dragging on the bottom right corner.
The DocumentWindow no longer responds to clicks. Impossible to move or resize it.

Setting the background alpha to 1.f solves the problem and the window reacts as expected after being resized.

Any ideas why this might be happening and if there is a work around I could in the meantime? It’s odd that Standalone isn’t impacted but VST3 is.

Thanks!

Constructor:

DocWinTestAudioProcessorEditor::DocWinTestAudioProcessorEditor (DocWinTestAudioProcessor& p)
    : AudioProcessorEditor (&p), audioProcessor (p)
    , docWin("Test", juce::Colours::magenta.withAlpha(0.2f), juce::DocumentWindow::maximiseButton | juce::DocumentWindow::closeButton, true)
{
    docWin.setSize(300, 300);
    docWin.setTopLeftPosition(400, 400);
    docWin.setAlwaysOnTop(true);
    docWin.setVisible(true);
    docWin.setResizable(true, true);
    docWin.setInterceptsMouseClicks(true, true);
    docWin.addToDesktop();

    setSize (400, 300);
}

pstitt01 · June 20, 2024, 3:04pm

It looks like the problem was introduced when Direct2D was implemented. It works fine on the commit just before this:

I’ve had a go at trying to track down why it acts differently between the Standalone and VST3 builds but I don’t have enough of an understanding of Direct2D.

Using the following code in the constructor means that the DocumentWindow passes the clicks through as soon as it becomes visible, rather than having to manually resize:

    docWin.setSize(300, 300);
    docWin.setTopLeftPosition(400, 400);
    docWin.setAlwaysOnTop(true);
    docWin.setVisible(true);
    docWin.setResizable(true, true);
    docWin.setInterceptsMouseClicks(true, true);
    docWin.addToDesktop();
    docWin.setSize(301, 300); // <- Resize the window here. If this line is included then window doesn't respond to clicks

Something that is happening in setSize() is breaking transparent DocumentWindows but I don’t see what it could be, not why it is different for Standalone.

I’ll keep looking but if anyone with more D2D knowledge than me can help that would be great

reuk · June 20, 2024, 6:55pm

This is a bit weird. I’ve started investigating, but haven’t made much progress yet. Interestingly, the issue doesn’t seem to affect all VST3 hosts. REAPER is affected, but the JUCE AudioPluginHost isn’t. So far I’m not sure what causes the difference in behaviour.

pstitt01 · June 21, 2024, 7:36am

Thanks for looking at this.

I did all my testing in Reaper, so that explains the difference with Standalone. I spent all day yesterday digging through the code but didn’t find much.

All I found was that overriding DocumentWindow::resized and adding the mouse listener back again allows the window to respond to clicks again but not for the whole bounds (it also causes massive glitches while resizing). Not sure if that is in any way helpful.

pstitt01 · June 27, 2024, 1:37pm

I’ve been doing a bit of debugging for this issue this morning. No real luck. I thought that it was because in Reaper the VST3 createView() function is not getting called after the second setSize() in the snippet above. In AudioPluginHost this is called after setSize(). But it’s actually the same with a non-transparent window, which works as expected, so it probably isn’t that…

The only other thing I have seen so far is the comments in the constructor of D2DContext, but I still don’t see what is happening differently between hosts that could make it relevant:

github.com

juce-framework/JUCE/blob/7bb71cc1ba4275ac86a744fd084706c39b393a9e/modules/juce_gui_basics/native/juce_Windowing_windows.cpp#L4680


      
          

          class D2DContext : public RenderContext

          {

          public:

              static constexpr auto name = "Direct2D";

          

              explicit D2DContext (HWNDComponentPeer& peerIn)

                  : peer (peerIn),

                    direct2DContext (std::make_unique<Direct2DHwndContext> (peer.getHWND(), peer.getComponent().isOpaque()))

              {

                  // Layered windows use the contents of the window back buffer to automatically determine mouse hit testing

                  // But - Direct2D doesn't fill the window back buffer so the hit tests pass through for transparent windows

                  //

                  // Layered windows can use a single RGB colour as a transparency key (like a green screen). So - choose an

                  // RGB color as the key and call SetLayeredWindowAttributes with LWA_COLORKEY and the key colour.

                  //

                  // Then, use an ID2D1HwndRenderTarget when resizing the window to flush the redirection bitmap to that same

                  // RGB color.

                  //

                  // Setting the window class background brush and handling WM_ERASEBKGND didn't work; Windows keeps filling

                  // the redirection bitmap in with solid black when the window resizes.

pstitt01 · July 5, 2024, 12:58pm

Hi @reuk, sorry to keep spamming this post. I have been looking into this again. To try to work around this issue I thought I’d try the software renderer and I’m encountering a different problem.

If I set the DocumentWindow to render using the software renderer (docWin.getPeer()->setCurrentRenderingEngine(0)) then I start hitting this assert:

github.com

juce-framework/JUCE/blob/606a7bc552b0737d2dee8feca3a203f167c33662/modules/juce_gui_basics/native/juce_Windowing_windows.cpp#L1094


      
                  SIZE size = { windowBounds.right - windowBounds.left,

                                windowBounds.bottom - windowBounds.top };

          

                  BLENDFUNCTION bf;

                  bf.AlphaFormat = 1 /*AC_SRC_ALPHA*/;

                  bf.BlendFlags = 0;

                  bf.BlendOp = AC_SRC_OVER;

                  bf.SourceConstantAlpha = layeredWindowAlpha;

          

                  [[maybe_unused]] auto ok = UpdateLayeredWindow (hwnd, nullptr, &pos, &size, hdc, &p, 0, &bf, 2 /*ULW_ALPHA*/);

                  jassert (ok);

              }

              else

              {

                  StretchDIBits (dc,

                                 x, y, width, height,

                                 0, 0, width, height,

                                 bitmapData, (const BITMAPINFO*) &bitmapInfo,

                                 DIB_RGB_COLORS, SRCCOPY);

              }

          }

Inserting auto err = GetLastError(); before the assert gives error 87 (This parameter is incorrect): System Error Codes (0-499) (WinError.h) - Win32 apps | Microsoft Learn

I hit the assert even when building as a standalone, so I don’t know if this is in any way related to the original error other than it also only happens for transparent DocumentWindows.

I tested in JUCE 7 and added the same assert but things seem to be working fine.

pstitt01 · July 30, 2024, 8:17am

@reuk Any timeline for this issue or is the best solution to roll back to the unbroken JUCE 7 for the time being? I have a release planned that relies on this and it would have been better to use JUCE 8 for some other features but this is a roadblock. Thanks!

reuk · July 30, 2024, 9:30am

I’m not able to guess when we’ll have a fix ready, unfortunately. This is still on my backlog, but my backlog is very full at the moment!

While I am planning to look at this, I’d like to mention that additional windows are very problematic in AUv3 (and to a lesser extent, AU), so if you’re planning on supporting macOS/iOS then you may need to consider an approach that avoids additional windows. In general I’d recommend to restrict all controls to the main editor window as much as possible.

pstitt01 · July 30, 2024, 10:31am

Thanks for the update. Just wanted to check if I should wait a few weeks for a fix or if it’s better to move ahead with JUCE 7. I’ll roll back to the working version for now.

I’m targeting AU/AUv3 so that shouldn’t be a problem but thanks for the warning.

reuk · August 23, 2024, 8:01pm

Thanks for your patience. I ended up having to make several different attempts at resolving this issue, which is why it took so long. Please let us know if you find any issues in the new implementation:

pstitt01 · August 26, 2024, 4:18pm

Thanks @reuk!

I’ve just tested and it all seems to be working fine but I keep hitting this jassert:

github.com

juce-framework/JUCE/blob/853e2052ff597a8051edec950f78c11f6ef09f3c/modules/juce_graphics/native/juce_Direct2DGraphicsContext_windows.cpp#L640


      
              // SetTarget(nullptr) so the device context doesn't hold a reference to the swap chain buffer

              HRESULT hr = S_OK;

              {

                  JUCE_D2DMETRICS_SCOPED_ELAPSED_TIME (owner.metrics, endDrawDuration)

                  JUCE_SCOPED_TRACE_EVENT_FRAME (etw::endDraw, etw::direct2dKeyword, owner.getFrameId());

          

                  hr = deviceResources->deviceContext->EndDraw();

                  deviceResources->deviceContext->SetTarget (nullptr);

              }

          

              jassert (SUCCEEDED (hr));

          

              if (FAILED (hr))

                  teardown();

          

             #if JUCE_DIRECT2D_METRICS

              owner.metrics->finishFrame();

             #endif

          

              return hr;

          }

This happens for both DocumentWindows added to both Standalone and VST3 plugins when clicking the maximise button. It only happens for transparent windows.

I also hit the jassert when I drag the DocumentWindow from one screen to another.

Testing in Release mode everything seems to be working as expected.

reuk · August 26, 2024, 7:54pm

Thanks for letting me know. An error returned by EndFrame just indicates that something went wrong while drawing the frame. Please could you try changing the constant on this line to D2D1_DEBUG_LEVEL_INFORMATION and checking the console/debugger output to see whether any additional information gets printed?

github.com

juce-framework/JUCE/blob/b12088a1f6a405d4ee85f0f2c43afb0babd8a46f/modules/juce_graphics/native/juce_DirectX_windows.h#L267


      
          public:

              DirectX() = default;

          

              auto getD2DFactory() const { return d2dSharedFactory; }

              auto getD2DMultithread() const { return multithread; }

          

          private:

              ComSmartPtr<ID2D1Factory2> d2dSharedFactory = [&]

              {

                  D2D1_FACTORY_OPTIONS options;

                  options.debugLevel = D2D1_DEBUG_LEVEL_NONE;

                  JUCE_BEGIN_IGNORE_WARNINGS_GCC_LIKE ("-Wlanguage-extension-token")

                  ComSmartPtr<ID2D1Factory2> result;

                  auto hr = D2D1CreateFactory (D2D1_FACTORY_TYPE_MULTI_THREADED,

                                               __uuidof (ID2D1Factory2),

                                               &options,

                                               (void**) result.resetAndGetPointerAddress());

                  jassertquiet (SUCCEEDED (hr));

                  JUCE_END_IGNORE_WARNINGS_GCC_LIKE

          

                  return result;

matt · August 26, 2024, 9:22pm

You may also need to install the Direct2D debug layer.

Matt

pstitt01 · August 27, 2024, 8:11am

I changed the constant and this is what I get:

D2D DEBUG ERROR - An operation failed because a device-dependent resource is associated with the wrong ID2D1Device (resource domain).
A breakpoint instruction (__debugbreak() statement or a similar call) was executed in reaper.exe.

D2D DEBUG ERROR - BeginDraw was called but will be ignored because the device context is in an invalid state.
A breakpoint instruction (__debugbreak() statement or a similar call) was executed in reaper.exe.

D2D DEBUG WARNING - EndDraw was called, but the rendertarget was not in a valid state. This may result from calling EndDraw without a matching BeginDraw.
D2D DEBUG WARNING - A Draw call by a render target failed [88990015]. Tags [0x0, 0x0].
JUCE Assertion failure in juce_Direct2DGraphicsContext_windows.cpp:640

With the debugging set Visual Studio also pauses on lines 616 and 617 of juce_Direct2DGraphicsContext_windows.cpp:

        // Start drawing
        deviceResources->deviceContext->SetTarget (getDeviceContextTarget());
        deviceResources->deviceContext->BeginDraw();

reuk · August 29, 2024, 12:21pm

Do you have multiple displays or graphics cards connected? I’m currently unsure how to reproduce the issue. The error text is fairly clear about what’s going wrong, but without being able to reproduce the problem it’s difficult to know why images are being incorrectly shared across devices.

pstitt01 · August 29, 2024, 12:55pm

I have another display connected to my laptop. When I unplug the display and just use the laptop screen I don’t hit the assert anymore.

reuk · August 29, 2024, 1:02pm

Interesting, thanks for letting me know. At the moment I can’t reproduce the issue with an external display connected to a Windows 11 laptop.

Are you using the laptop screen too, or is the lid shut when the assertions fire?
Do you know what GPUs the laptop has available? Does it have discrete graphics as well as integrated graphics?

pstitt01 · August 29, 2024, 1:23pm

Yes, I was using both screens when I hit the asserts.

When I close the lid on my laptop and just use the external screen I don’t hit the assert.
There are two GPUs built in to the laptop: Intel Iris Xe Graphics and NVIDIA GeForce RTX 3060 Laptop GPU

While interacting with the window it looks like it is mostly the Intel card that is bring used but there is perhaps some small (2-3%) use of the NVDIA.

reuk · August 29, 2024, 2:34pm

Thanks for the extra details, I’ve managed to find a computer setup that reproduces the issue. I’ll investigate and update this thread once there’s a fix available.

reuk · September 5, 2024, 12:27pm

Thanks again for your assistance in tracking down this issue. The following patch should fix things:

Topic		Replies	Views
The JUCE 8 Preview branch is available now! News and Announcements	187	8246	June 10, 2024
Direct2D Windows	59	6817	March 30, 2022
v1.24 General JUCE discussion	33	1256	May 12, 2017
Direct2D Part Deux : 2 Direct 2 Furious Windows	24	2749	August 14, 2023
High dpi issue on Windows with VST3 plugins Audio Plugins	35	8905	November 3, 2021

BR: DocumentWindow broken in VST3 when transparent since JUCE 8

Purchase

Discover

Learn

Support

About

Events

Related topics

Purchase

Discover

Learn

Support

About

Events