BUG? Popup Menu Background and Logic Silicon

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

FYI, this didn’t work for me, seems to negate the call to setOpaque( false ). I’ve just gone with removing rounded recangles for Logic.

Hi, is this issue also responsible for the occasional flashing pink of the background when opening the popups - this isn’t consistent but happens every now and then.

thx

The magenta backgrounds are present on all secondary windows in out-of-process-hosted AUv3 plugins. If you’re testing in AUv3, then the answer is probably yes, but there’s not enough detail in the question to know for sure. I haven’t seen the exact issue you’re talking about. Do you see the problem in all formats, or in specific ones? On which platforms, and in which hosts?

1 Like

Hi, as with the corner issue, only in Logic/M1.

thx

Hi @reuk

I’ve tried this trick but the results are only partially ok. First of all, I’m on iPadOS (Standalone and AUv3), and I’ve got a couple of comboboxes inside some components that are AudioProcessorEditor’s children.
The structure:

  • AudioProcessorEditor
    • customComponent1
      • combobox1
    • customComponent2
      • combobox2

Standalone app:
I pass my AudioProcessorEditor to the LnF class using getParentComponent() and everything works as expected: the popup related to the combobox is shown correctly and it is actually able to expand over the boundaries of its parent component (and that’s right since I’ve passed the whole ProcessorEditor and not a “this” reference).

AUv3:
If I do the same thing, nothing happens: the combobox popupmenu does not show up. If I pass “this” the popupmenu shows up, but it is restricted inside the parent component, and therefore is both ugly and difficult to use (it cannot go over the boundaries of “customComponent1” and so on for the others).

Is there something that I’m doing in the wrong way? This problem happens only on iPadOS in AUv3, on desktop everything is good