BUG? Popup Menu Background and Logic Silicon

I see, perhaps a bit overkill to do it just for Logic Pro. I’ve sent the bug report, hopefully, it’s going to be fixed soon. Thanks again!

That LookAndFeel mod works fine. Tested with the same project and now it renders correctly. I need to test it further on other DAWs on Silicon.

Thanks @reuk

Any feedback from Apple regarding that bug?

There is the same issue with the sliders’ popups (cf setPopupDisplayEnabled()).

I’ve sent two bug reports over the months. One through an online form, one through Feedback Assistant. No answer so far. I had a contact at Apple suggesting me to use Feedback Assistant, but he’s also not replying anymore, so not sure where to go from here.

Small update, I’ve just updated to Logic Pro 10.6.3 on Big Sur 11.3 and the bug is still there. I’ve contacted another person at Apple and the feedback I submitted was moved to macOS. This is their response:

We found the feedback, it’s on the macOS side – we already assumed that it had nothing to do with Logic. My guess would be: it happens, because Logic is built against a recent SDK, which changes some behaviors inside macOS.

Ok, I finally have a full answer and will update the ProAudio Seed Release Notes accordingly. Please check them regularly.

Windows opened by the plugin might have a subtle magenta tinting. This is security feature, not a bug. It avoids that malicious code can open a window which overlays system windows. There are a couple of ways to avoid this tinting:

  • Make the window less transparent (75% or more opacity will avoid this tinting)
  • Call -[NSWindow addChildWindow:…]. This will confine the magenta to the remote view, which spawns the child.
  • Use a standard window to obtain rounded corners without using a transparent background color.
2 Likes

Hi Markus, thank you for the update!
Reducing the transparency unfortunately is not great with rounded corners.
Regarding the other solutions, I’m not sure if JUCE can implement them directly? I hope so.

2 Likes

Well, there is another really crazy option, I haven’t even mentioned: you could use standard macOS popup menus…

1 Like

@reuk any thoughts on that?

The odd thing as mentioned before, Logic Pro is the only DAW affected by this (afaik). So, creating a workaround for just one DAW seems a bit extreme. But still…

Unfortunately, popup menus are also used in ComboBoxes to display the popup list of values, and having a native menu appearing under a custom designed widget would feel strange.

And also, It’s not just an issue with popup menus: the same magenta coloring is overlaid to rows of lists when they are dragged around, for example. And I suppose also to the semi-transparent drag image that appears when a drag gesture is started with DragAndDropContainer::startDragging()

Unfortunately I don’t think any of the suggestions would resolve the problem.

This won’t allow popup windows to have completely transparent rounded corners.

This initially seemed like a viable solution, but it seems that any part of the child window that is not on top of the parent window is still painted with a magenta background. To test, I applied this patch:

childwindow.patch (2.9 KB)

Then, I built the DSPModulePluginDemo AU and loaded it in Logic on an M1 mac. Popup menus which are not entirely contained by the editor window sill have partially magenta backgrounds.

Screenshot 2021-06-02 at 13.11.24

This is not a general solution, it only fixes the case where the desired corner radius matches that set by the OS. It doesn’t fix the issue for windows with a translucent background.

This would force the menu to use OS styling, which may not be acceptable to some developers. It would also only provide a solution for PopupMenus. This solution would not work for arbitrary floating widgets such as dragged items, tooltips and so on.

All this is to say that I still think the solution that will yield the most consistent results across platforms is to avoid opening new top-level windows entirely, and to draw widgets such as menus, tooltips, and dialogs directly into the editor window wherever possible.

5 Likes

Thank you. This is ok for small menus, but it’s awful for bigger ones. We’ll need to rewrite a few things to make them look at least decent.
I’m thinking of adding this workaround just for Logic.

I was able to repro with AudioPluginHost built for M1 with an AU plugin built for Intel. Most likely if you can’t repro this you’re launching an Intel app on an M1.

It’s been a while since this post. Is there an actual solution?

No. As mentioned earlier, this is due to the cross-process hosting mechanism introduced on ARM macs. Apple is not planning to add a workaround, as far as I know.

The best solution is still the one I mentioned above: avoid opening new top-level windows entirely, and draw widgets such as menus, tooltips, and dialogs directly into the editor window.

2 Likes

Ok so, I need to rewrite my look and feel implementation as using @reuk suggestion “topLevelComponent” won’t work when the look and feel is implemented as a SharedResourcePointer:

struct MainLookAndFeel
{
    MainLookAndFeel()  { LookAndFeel::setDefaultLookAndFeel (&lnf);    }
    ~MainLookAndFeel() { LookAndFeel::setDefaultLookAndFeel (nullptr); }
    MyLookAndFeel lnf;
};

SharedResourcePointer<MainLookAndFeel> mainLookAndFeel;

The first instance of the plugin will be ok, but the second will override the topLevelComponent, causing the popups from the first plugin to be opened in the second plugin.

Any suggestion on what would be the proper way of implementing something like that?

getParentComponentForMenuOptions (const PopupMenu::Options&) allows you to discover the popup menu’s target component. From there, you can call getTopLevelComponent() to find the outermost component.

1 Like

I casually noticed that this workaround is not working any longer. Despite I have my LaF class taking the topLevelComponent, the behavior on Logic is not the same as before: magenta overlay on transparencies and menus going out the plugin boundaries.

EDIT: I tested a plugin built with 6.0.8 and it works as expected on Logic Pro X. New plugins and updates I’m building with 6.1.5 (so no changes made on the LaF), are showing the issue. I need to figure out what changed in between and why Component* getParentComponentForMenuOptions (const PopupMenu::Options&) override won’t get called.

Related to this.
getParentComponentForMenuOptions is not called unless you use setDefaultLookAndFeel, which I think it’s a bug.

1 Like

@reuk I can confirm that the problem is because of plugins running in their own process. I could trigger the same pink issue with an Intel plugin running in Silicon Reaper. This so called security measure of apple is stupid to say the least