[wpe-2.46] GPU spikes with hidden animations on Amazon Luna app

[filipe-norte-red]

Context

On the Luna App, when starting a game (e.g. Shadow of the Tomb Raider), GPU memory spikes are seen on 2.46 (several tens of MB), while on 2.38 they are much lower or nearly non-existing. Reproduction sequence is as follows:

1. Press Ok on "Jugar ahora" button on the game overview screen

2. A game controller selection screen appears with a notification message being shown for a brief moment on the top right corner. Press ESC/BACK to remove the controller selection screen

3. A notification message appears again on the top right corner and the game is shown in the background (video layer)

4. Exit the game to return to the game overview screen.

On wpe-2.38

The GPU memory evolves as shown below.

Each horizontal line corresponds to a 20 MB increment, so right before pressing OK to start the game, the app is using around 50MB of GPU memory.

When the notification message is displayed on screen, we see a few calls to acquire a BitmapTexture instances (via acquireTexture()), but these don't repeat while the message remains on screen and no other interactions are performed. Shown is width, height and flags (flag = 3 with depth buffer, flag = 1 without depth buffer):

w = 241 h = 258 f = 1
w = 512 h = 258 f = 1
w = 639 h = 258 f = 1
w = 512 h = 258 f = 1
w = 241 h = 258 f = 1 

On wpe-2.46

There are higher GPU memory spikes. This is observed when the game starts, but also when the notification message is shown. Changes from pull request #1597 (merged) and #1616 (merge pending) with a max texture size of 2000 improve this, but there is still a higher GPU mem usage compared to 2.38.

In this case, when the notification message is displayed on screen, there are much more calls to acquire a BitmapTexture:

w = 711 h = 258 f = 3
w = 3291 h = 258 f = 1
w = 753 h = 258 f = 1
w = 3150 h = 258 f = 1
w = 2889 h = 258 f = 1
w = 512 h = 258 f = 1
w = 2057 h = 258 f = 1
w = 1871 h = 258 f = 1
w = 241 h = 258 f = 1
w = 1440 h = 258 f = 1
w = 1238 h = 258 f = 1
w = 789 h = 258 f = 1
w = 743 h = 258 f = 3
w = 754 h = 258 f = 1
w = 730 h = 258 f = 3
w = 734 h = 258 f = 3
w = 737 h = 258 f = 3
w = 733 h = 258 f = 3
w = 732 h = 258 f = 3 

Moreover, the calls continue repeating while the notification message is on screen (although reuse from pool takes place), which is a different behavior from 2.38.

Analysis

Tried to extract the layout for the problematic scenario and creating a test page to reproduce it, but am unable to reproduce the spikes with similar amplitude using a test page (using CSS from original content). Focusing on the middle spike when the notification message is displayed, the following findings where gathered:

Spike is influenced by notification message animations

The app has a div under which it will build elements to show a notification message to the user (Toast):

<div class="Toastify" id="information"></div>

The child tree will contain the following div with a progress bar:

<div class="Toastify__progress-bar Toastify__progress-bar--animated Toastify__progress-bar--default"
 style="animation-duration: 60000ms; animation-play-state: running; opacity: 0;">  </div>

Disabling animations using the style below added to the "information" div causes the middle spike (notification message shown) to be almost not existing:

<style>
    #information,
    #information * {
      animation: none !important;
    }
</style> 

It also improves the transitions when we enter the game (to the game controller selection screen):

Texture acquisitions stop after message is shown

Previously on 2.46, while the notification message is shown we see repeatedly attempts to get a BitmapTexture. This appears to be related with an animated progress bar associated with the notification message mentioned above, despite that opacity is set to zero! Setting it to a non-zero value to display the 5 pixel height progress bar does not seem to affect the memory usage pattern.

With the animations disabled, we don't see the repeated attempts anymore.

Note: The texture acquisition pattern on 2.38 does not seem to be influenced by changing the opacity. CSS and layout seem to be identical to 2.46. Changing the opacity value to show the progress bar on 2.38 does not start triggering repeated texture acquisitions, so it is not a matter of improper opacity handling on 2.46 with respect to the animations rendering.

Issue

• GPU memory usage on 2.46 has higher spikes compared to 2.38
• Opacity set to zero still causes repeating texture acquisitions and GPU mem spikes

Can this be analyzed with regards to the "opacity: 0;" property behavior and see if the mem usage can be optimized?

Thank you