[Impeller] Impeller uses more memory than skia when sliding the page in android applications.

[FridayAutum]

Steps to reproduce

1.Open the application.
2.Slide the page.
3.Capture profile memory snapshots by using Flutter devtool.
I found the difference in my android application,then I retested this in flutter-wonderous-app, the phenomenon is consistent.
The average memory data of impeller is always higher than skia.
This problem is more obvious in my app, which is about 20MB higher in comparison.
Here is the "Dart Heap" data captured in the flutter-wonderous-app.
Device1
Impeller

Skia

Device2
Impeller

Skia

Code sample

https://github.com/gskinnerTeam/flutter-wonderous-app

What target platforms are you seeing this bug on?

Android

OS/Browser name and version | Device information

Device1:Redmi K70 Pro OS:Xiaomi HyperOS(Android)
Device2:Oneplus 11 OS:ColorOS(Android)

Does the problem occur on emulator/simulator as well as on physical devices?

Unknown

Logs

Logs

[Paste your logs here]

Flutter Doctor output

Doctor output

[✓] Flutter (Channel master, 3.27.0-1.0.pre.205, on Ubuntu 24.04.1 LTS 6.8.0-47-generic, locale zh_CN.UTF-8)
• Flutter version 3.27.0-1.0.pre.205 on channel master at /home/mi/workspace/devkit/flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision bade559 (8 小时前), 2024-10-23 16:35:10 -0700
• Engine revision 73c54fadf5
• Dart version 3.7.0 (build 3.7.0-58.0.dev)
• DevTools version 2.40.1

[✓] Android toolchain - develop for Android devices (Android SDK version 35.0.0)
• Android SDK at /home/mi/Android/Sdk
• Platform android-35, build-tools 35.0.0
• Java binary at: /home/mi/.local/share/JetBrains/Toolbox/apps/android-studio/jbr/bin/java
• Java version OpenJDK Runtime Environment (build 17.0.11+0-17.0.11b1207.24-11852314)
• All Android licenses accepted.

[✓] Chrome - develop for the web
• Chrome at google-chrome

[✗] Linux toolchain - develop for Linux desktop
✗ clang++ is required for Linux development.
It is likely available from your distribution (e.g.: apt install clang), or can be downloaded from https://releases.llvm.org/
• cmake version 3.28.3
✗ ninja is required for Linux development.
It is likely available from your distribution (e.g.: apt install ninja-build), or can be downloaded from https://github.com/ninja-build/ninja/releases
• pkg-config version 1.8.1
✗ GTK 3.0 development libraries are required for Linux development.
They are likely available from your distribution (e.g.: apt install libgtk-3-dev)

[✓] Android Studio (version 2024.2)
• Android Studio at /home/mi/.local/share/JetBrains/Toolbox/apps/android-studio
• Flutter plugin version 81.1.3
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 17.0.11+0-17.0.11b1207.24-11852314)

[✓] IntelliJ IDEA Ultimate Edition (version 2024.2)
• IntelliJ at /home/mi/.local/share/JetBrains/Toolbox/apps/intellij-idea-ultimate
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.94.2)
• VS Code at /usr/share/code
• Flutter extension version 3.98.0

[✓] Connected device (2 available)
• Linux (desktop) • linux • linux-x64 • Ubuntu 24.04.1 LTS 6.8.0-47-generic
• Chrome (web) • chrome • web-javascript • Google Chrome 129.0.6668.100

[✓] Network resources
• All expected network resources are available.

[huycozy]

I checked this on my device Pixel 7, Android 14 but couldn't see the issue. Tested on Flutter stable 3.24.3 and master 3.27.0-1.0.pre.206, Dart Heap is around 20 to 21 MB with and without Impeller.

In your report, the gap of Dart Heap w/wo Impeller on the first device is also minimal and may not be noticeable (24.5 vs 25.3 MB). However, the gap becomes more apparent on the second device (28.6 vs 21 MB). Keeping this as a device-specific issue.

[FridayAutum]

I used another device retesting this issue,through using " adb shell dumpsys meminfo com.gskinner.flutter.wonders |grep "TOTAL PSS" " .
I tested the memory information when the page was stationary or sliding(Slide up and down),the results were somewhat unexpected.
Vulkan Version:1.3.0(dEQP:2022-03-01)
OpenGL ES Version:3.2 V@0676
skia

Impeller

[jonahwilliams]

@FridayAutum impeller doesn't impact dart heap (except indirectly via rendering more/less frames) and dart heap doesn't include any native objects

[FridayAutum]

Thanks for the correction.I found that the range of the memory information obtained by "adb shell dumpsys meminfo" on different mobile phones is also different, which may have interfered with the data I got. I will submit this problem to my team to see where the specific differences are.

[FridayAutum]

I used a script that can slide pages stably and test the memory information every second, and found a possible memory leak problem.The overall PSS memory usage shows a curve-like upward trend which also exists in my application.I ran the same test on both the stable branch and the master branch.The problem still exists in the master branch, but it is better than the stable branch.

adb shell dumpsys meminfo com.gskinner.flutter.wonders | grep "TOTAL PSS"
Impeller Enabled

Stable


Master

[FridayAutum]

This is how i test this issue.

screenrecorder.mp4

[FridayAutum]

We tested our own app and Wonderous app on different phones and found that this problem exists on both.This might not be a device-specific issue.

[jonahwilliams]

@FridayAutum what are the numbers comapred to Skia? its difficult for me to tell what the actual diff is?

[FridayAutum]

In terms of memory growth rate, Impeller using Vulkan as backend has a higher growth rate than the other two(Skia,Impeller+OpenGLES). I think it may be a problem in the memory allocation and recycling mechanism related to Vulkan?
Skia(1)

Skia(2)

Impeller Vulkan(1)

Impeller Vulkan(2)

Impeller Opengles(1)

Impeller Opengles(2)

[jonahwilliams]

Some notes from testing on my end:

• I don't see any evidence for a memory leak though, memory usage is stable, and increases in memory usage correlate with how the application loads and caches large images.
• I see very different allocation behavior, which I'd sort of expect given that these are entirely different backends. There may be some more opportunity to tune the Vulkan backend behavior.

It looks like on Impeller we start with a larger initial memory usage (possibly from the initial image upload) and then drop down. Whereas skia starts very low and then jumps up as it decodes more images. I'll need to look more into finding a breakdown of the graphics memory usage so I can correctly attribute the allocation to the different parts of our backend.

Impeller Vulkan

Skia

[jonahwilliams]

I was able to get the memory usage to more closely match skia by adjusting the initial size of our VMA heap. I suspect that the defaults we are using are not optimal for an Android application and need adjustment. The initial pool size for the VMA allocator is 256 MB.

diff --git a/impeller/renderer/backend/vulkan/allocator_vk.cc b/impeller/renderer/backend/vulkan/allocator_vk.cc
index 18ef93d8e6..43d0e3815c 100644
--- a/impeller/renderer/backend/vulkan/allocator_vk.cc
+++ b/impeller/renderer/backend/vulkan/allocator_vk.cc
@@ -14,6 +14,7 @@
 #include "impeller/renderer/backend/vulkan/device_buffer_vk.h"
 #include "impeller/renderer/backend/vulkan/formats_vk.h"
 #include "impeller/renderer/backend/vulkan/texture_vk.h"
+#include "third_party/swiftshader/include/vulkan/vulkan_core.h"
 #include "vulkan/vulkan_enums.hpp"
 
 namespace impeller {
@@ -84,6 +85,7 @@ static PoolVMA CreateBufferPool(VmaAllocator allocator) {
   VmaPoolCreateInfo pool_create_info = {};
   pool_create_info.memoryTypeIndex = memTypeIndex;
   pool_create_info.flags = VMA_POOL_CREATE_IGNORE_BUFFER_IMAGE_GRANULARITY_BIT;
+  pool_create_info.minBlockCount = 1;
 
   VmaPool pool = {};
   result = vk::Result{::vmaCreatePool(allocator, &pool_create_info, &pool)};
@@ -145,6 +147,7 @@ AllocatorVK::AllocatorVK(std::weak_ptr<Context> context,
   allocator_info.device = device_holder->GetDevice();
   allocator_info.instance = instance;
   allocator_info.pVulkanFunctions = &proc_table;
+  allocator_info.preferredLargeHeapBlockSize = 64;

[jonahwilliams]

I think with some adjustments we can actually use much less memory than the existing Skia backend.

[FridayAutum]

I also found a problem still exists in version 3.24.4 but fixed in master.The application's memory usage data keeps growing due to frequent page switching, from the initial 291MB to the final 890MB(Mainly in NativeHeap).(I used a script that can perform the action in the video)(Test time:1 Hour)

Similar problems also exist in my application.Is there any way to circumvent or fix this in the stable version(3.24.4)?

demoslide.mp4

Begin

End

[jonahwilliams]

I'm not certain, we've done a lot of work since 3.24. You might check if the current beta 3.27 (I think) reproduces the issue or not.

[FridayAutum]

Much appreciated,It will not reproduce in 3.27-pre.

[jonahwilliams]

@FridayAutum changes to the VMA settings landed in 7edcacb . I've run locally and I believe memory usage is closer to Skia levels, but it would be great if you could test that out as well too.