BR: JUCE 8.0.8 / Android: editor child components disappear completely

Android
1

I’ve come across a bug that didn’t happen on earlier versions of JUCE, where editor child components that have the ‘setBufferedToImage’ flag set to true disappear when moving an app to the background and bringing it back to the foreground. This seems to only happen when attaching an OpenGL context, and when a component is using the bufferedToImage flag.

Simple code to reproduce the issue (tested on a variety of Samsung devices):

#pragma once

#include <JuceHeader.h>
#include "PluginProcessor.h"

class Editor : public juce::AudioProcessorEditor
{
public:
    
    // ===============================
    class BufferedComponent : public Component
    {
        public:
        BufferedComponent()
        {
            setOpaque(false);
            setBufferedToImage(true);
        }
        void paint(juce::Graphics& g) override
        {
            g.setColour(juce::Colours::white);
            g.fillRect(0, 0, 50, 50);
        }
    };
    
    // ===============================
    Editor (Processor& p) : AudioProcessorEditor (&p)
    {
        m_openGLContext.attachTo(*this);
        m_bufferedComponent.setBounds(100, 100, 100, 100);
        addAndMakeVisible(m_bufferedComponent);
        setSize (400, 300);
    }
    
    ~Editor() override {};

    void paint (juce::Graphics& g) override
    {
        g.fillAll (getLookAndFeel().findColour (juce::ResizableWindow::backgroundColourId));
    }
    
private:
    juce::OpenGLContext m_openGLContext;
    BufferedComponent   m_bufferedComponent;
    JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (Editor)
};

To reproduce the issue:

  • Create a JUCE plugin with the editor code from above
  • Export for Android Studio
  • Compile and run the app. Initially the white square that is drawn as part of the BufferedComponent will show correctly (it has 1/4 of the size of the component itself)
  • Minimize / put app in background, and then bring it back to the foreground: the whole BufferedComponent is now drawn as a black square and its contents has disappeared.
2

Another Android issue: filling a child component with a colourgradient, using fillAll() doesn’t fill the complete component and leaves pixel garbage in the bottom 30 pixels or so.

3

And yet another Android issue: if a button sits close to the right edge of the screen, and spawns a popup menu, the popup menu appears on the left side of the screen, quite far away from the target component that was set in the PopupMenu::Options struct…

4

Hi there, I’d like to see if I can reproduce these issues. Could you share your main class as well? And are you testing against the develop tip?

5

Please could you let us know which version of JUCE you’re using for testing?

It would also be helpful to know the Android version(s) you’ve tested.

6

What I did is to create a new plugin project using the projucer, left pretty much all settings at default except for pulling in the OpenGL module, and enabling microphone access in the permissions settings. This was using the master branch of JUCE 8.0.8. Then simply replace the editor with the editor code above. I’ve attached a small zip file with the projucer and C++ files of the whole project.

I’ve been able to reproduce the issue in Debug mode on the two devices I’ve used for testing; a Samsung tab S7 running Android 13, and a Samsung S21+ running Android 15.

I’ll test the develop branch as well and report back asap.

AndroidBugReport.zip (8.3 KB)

7

Latest develop branch also has the issue. Simply open the JUCE app - you’ll see the correct white rectangle, then switch to another app, and switch back to the JUCE app. After switching, the one child component of the Editor shows up as a black square.

8

Thanks for reporting. I’m able to repro this issue, and I’ve started work on a fix.

So far I haven’t been able to repro this. Please can you provide a small code example that shows the problem? I’m guessing that this needs specific circumstances to trigger that might include the specific gradient parameters, bufferedToImage state, and OpenGL context state.

How are you opening the menu? Are you using PopupMenu::Options{}.withTargetComponent (&button)? Again, a code example would be helpful. To test this, I tried modifying the MenuPage of the WidgetsDemo, changing the final line of the MenuPage::resized() function like so to move the buttons over to the right hand side of the screen:

box.performLayout (getLocalBounds().removeFromRight (100));

When I click the buttons in the Android simulator, the menus open under the buttons, or over the buttons in the case of long menus. Note that if the target component is partially off the screen, the PopupMenu will still be positioned so that it is entirely on-screen if possible, so the left hand side of the menu is not guaranteed to be flush with the left hand side of the button.

9

Thanks @reuk for looking into these things; let me know if you want me to run more tests.

On the popup menu issue: I’ve managed to fix this making some local adjustments in a modified version of the JUCE PopupMenu in alignment with JUCE 8.0.8 and some of the changes that are currently on develop. I tried to reproduce the issue with the default PopupMenu and couldn’t repro it either; so this seemed an issue on our end with the customised PopupMenu class and their interaction with recent changes in JUCE 8.0.8 - apologies for the confusion!

The main reason we’re using a modified PopupMenu is that the standard PopupMenu is somewhat cumbersome on a touch screen when using sub menus. For example, it seems difficult to open a sub menu but then wanting to go back and open a different sub menu using touch events. It would be great if at some point the JUCE PopupMenu would become a bit more touch friendly.

On the colour gradients: I see issues in complex projects and have been trying to create a simple project to reproduce it. So far I haven’t been able to do so. I’ll keep trying and let you know if I can create something. Interestingly, the pixel garbage I’m seeing with gradients is often related to the contents of the component that went missing after putting an app into the background (in a somewhat scrambled version). So perhaps this gradient issue is related to the disappearing components observation?

10

Have you considered with popupmenu’s that they should be replaced with a sliding drawer paradigm on mobile platforms, as a means of future-proofing the UI?

This is a far more user-friendly approach, imho. Although, I acknowledge that it requires re-thinking the overall design of the UI…

I’ve replaced all popupmenu elements in my plugins with sliding drawers (responsive UI-style), and this has basically solved the user confusion that results from having popupmenu/submenu child windows to manage. Instead of, say, a “load preset” button popping up a sub-menu that has a modal impact, the main UI “slides over” and a sliding drawer is expanded to contain the preset list.

This resulted in a vast improvement in usability, which applied well - both to desktop and touch-based targets, and essentially side-stepped the whole issue of window->popupmenu->submenu->popupmenu hierarchies being difficult to navigate.

Especially with regards to this issue:

For example, it seems difficult to open a sub menu but then wanting to go back and open a different sub menu using touch events.

It seems to me that a potential fix would be a PopupMenu extension which turns it into a sliding drawer on touch interfaces, functioning as a sub-component of the UI, rather than a clumsy child window with modal impact.

11

Yes, submenus are not ideal on mobile devices.

Apart from a sliding drawer, another possibility is a menu system where instead of opening sub menus you expand and collapse categories. This should normally not require re-thinking the overall design of the UI. For an example one can take a look at imGui, where this is used extensively.

12

Ah yes, thanks for sharing thoughts. And I agree popup menus / submenus are not ideal for mobile; but sometimes they can be useful, for example to have a consistent UI/UX experience between desktop and mobile.

I’ll give dynamically expanding / sliding menu systems some thought!

13

Thanks for the issue report. There’s now a fix for the issue where OpenGL-backed Image content can go missing when moving the app to the background:

Please try out the changes and let us know if you run into any new problems.

14

Thanks @reuk for looking into this!

I just tested the fix; it does bring back the content in OpenGL-backed component that have the ‘setBufferedToImage’ flag, but if there is any content in it (like text), it’s now re-appearing upside down (flipped vertically) when the app is pushed to the background and foreground again?

15

Sorry about that, I obviously didn’t test enough. This commit should fix the issue:

16

Great, that fixed it! Thanks much @reuk