Skip to content

[linux/arm64] fix: Long loading times on Raspberry Pi 5 (several minutes) #391

Open

Description

@kerberjg

When loading example_app, the system will become unresponsive and the Flutter view will be frozen displaying a CircularProgressIndicator - for several minutes. While I wasn't yet able to exactly time the loading process, all of my attempts have been somewhere within the 2-5 minutes OoM.

To make sure this is related to scene/asset loading, I re-checked loading another scene after the app is already open: got similar loading times, meaning this isn't related to Flutter itself.

What's odd is that the CPU doesn't seem to be maxed-out, but rather sitting at 20-70%. But the entire system being unresponsive is really worrying. Similarly to #388, there's just something about flutter_scene the OS/hardware really doesn't like - when stress testing non-3D Flutter apps on the same unit the system does not freeze.

For context, active cooling is installed on my unit.

Test environment:

  • Raspberry Pi 5, 16GB
  • RaspberryPi OS / Debian 13 Trixie
  • linux/arm64, glibc 2.41
  • VideoCore VII GPU, supporting OpenGL ES 3.1, Vulkan 1.2
  • Flutter (Channel main, 3.48.0-1-0.pre-676)

Activity

  1. bdero commented on Sep 9, 2026

    @bdero
    Owner

    Which particular scenes were you having trouble with?
    The particles example generates frame flipbooks + all of the geometry/textures at runtime, and so I would expect the load time to be very large for that one. Some of the other examples download GLBs from the internet.

  2. kerberjg commented on Sep 9, 2026

    @kerberjg
    Author

    I will take some time to go through them one-by-one tomorrow, but going from memory it was anything that wasn't just a primitive shape. The ones that did download GLBs would be stuck after the download said to be complete (which wouldn't be a problem anyway, I have 1Gbps symmetric + wired). I noticed they all get stuck between lines of "Unpacking glTF".

    Some scenes (like Sponza) would fail to load altogether, with a flurry of "Failed to create texture" messages - I can provide more accurate logs tomorrow.

  3. bdero commented on Sep 9, 2026

    @bdero
    Owner

    Thanks. Another thing I noticed is that the videos appear to be in debug mode -- based on what you've provided, my guess would be that the bottleneck is almost entirely CPU, and so switching from debug to release mode should help some as well.

    By the way, could you confirm if you're running with Impeller OpenGLES or Vulkan? The bug you came across in #387 looks like something I might expect based on how the framebuffer cache works in the GL backend, but it occurs to me that the Raspberry PI 5's graphics stack actually supports Vulkan 1.2 (Impeller's minimum requirement is Vulkan 1.1, but can get disabled if certain extensions are missing). It should print the version you're using from the app startup log.
    Whoops, I'm being a dummy, the main fork is GLES only for Linux right now. I know there's at least one Scene user in a similar boat to Toyota Connected with a custom Linux embedder using Vulkan, which is how they are deploying Scene. If possible, I'd try running things through your actual embedder if you can as well, although we should be able to get things running pretty well on a Raspberry Pi 5 either way.

  4. added
    bugSomething isn't working.
    performanceFrame rate, memory, or runtime cost regressions.
    on Oct 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working.performanceFrame rate, memory, or runtime cost regressions.platform:linux

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions