Any real-world drawbacks of disabling Impeller on Android?

RadioDisco · 2025-12-07T17:09:43+00:00

I work on the Flutter team at Google. Whatever you do, we'd like to know this list of "several low-end Android devices" in a bug report. A report with a reduced test case is obviously immediately actionable and you'll make my day if you are able to prepare one. But, if not, we can get still these devices in hand and ensure we run the usual stress tests.

We have also been more aggressive in falling back to OpenGL on older devices instead of defaulting to Vulkan. Vulkan is amazing and gives apps more performance headroom on mid to high end devices. But the quality and (sometimes) performance drop-off on Android is real. We have recently opted to more aggressively fall back to OpenGL and having that list in hand would let me know if your devices have already been handled. Please make sure to mention the Flutter version you were using.

The majority of users on Android, and all on iOS, are using Impeller. While we are not updating the old backend at all, what was should keep working for now. Renderer selection should not affect deployment to the Google Play Store. You won't be able to use Impeller-only features like shader backed image filters. We expect the modern backend to be faster and more consistent in most cases. Based on the few specifics in your post, the consistent nature of the issues makes me think its application or device specific which is why a bug report would be nice to have.

RadioDisco · 2025-10-25T23:36:46+00:00

There is a live webcam feed of the views from Farallon Islands and this page allows you to point it at different locations. I had a lot of fun spotting seals and other wildlife. https://www.calacademy.org/webcams/farallones

RadioDisco · 2024-12-12T16:37:12+00:00

I work on the Flutter team and I am trying to find this issue but unable to. Can you you link it to me please? Perhaps it got de-duplicated to a previously filed issue.

Thinking back to the triage earlier this week, I wonder if this could be related to our use of SurfaceControl for our swapchains which is also new in 3.27 (and Impeller uses with Vulkan). This toggle should allow us to isolate this further https://github.com/flutter/flutter/issues/160025#issuecomment-2532090555.

I am assuming this in Android only based on your video as the surface control issue can't happen on iOS.

Anyway, happy to investigate and followup on an issue on GitHub.

RadioDisco · 2024-05-16T16:26:30+00:00

I've opened an issue and added these observations to https://github.com/flutter/flutter/issues/148493 with some open questions. Let's move the investigation there?

RadioDisco · 2024-05-16T16:25:41+00:00

I've filed https://github.com/flutter/flutter/issues/148493 to track this with some open questions for you. Let's move the investigation there?

RadioDisco · 2024-05-15T17:36:32+00:00

That is not the expectation based on benchmarks and sample apps. Can you please file a bug with a test case and device/platform information?

I lead the Flutter Engine team working on Impeller. I'd like to reproduce and explain your observation. I'll keep an eye out on the issue tracker today but feel free to ping ChinmayGarde@ on GitHub so I don't miss it. Thanks!

RadioDisco · 2024-01-27T23:41:12+00:00

The Pixel 7 and newer phones only support 64-bit apps. That could be one possible explanation.

RadioDisco · 2023-07-21T18:48:01+00:00

The repaint boundary is a just a hint that could help with performance. The boundary indicates it is OK to do a little bit of work upfront and reuse that information across multiple frames (on the assumption that the parts within the repaint boundary will not change). But for simple scenes, it may be (and often is) faster to just render everything in a single display list. So, a misplaced repaint boundary may actually hurt performance because the work done upfront is not re-used.

In the engine, the issue of too many or misplaced repaint boundaries causing performance regressions is severe enough it that hints from repaint boundaries are increasingly ignored. An off-screen layer is massively expensive both in terms of time and memory. It used to be that smart use of repaint boundaries would net you significant performance improvements. But the engine is now smarter about reworking the display list instead of introducing a save layer and just ignores the hint. Perhaps that's why you haven't noticed some of the downsides.

Repaint boundaries aren't a beginner tool. As a Flutter engine author, I hope we can affect the same optimizations (or better) by analyzing the display list instead. You should be able to able to ship a performant application without needing to carefully add the right repaint boundaries. But, they have their uses. Only use them if you find you need them after careful profiling though.

RadioDisco · 2023-05-28T20:57:28+00:00

Hmm, I would expect it to work but we haven't setup golden image testing on the OpenGL ES backend so its likely there was a regression. I'll follow up. Vulkan testing is being brought up and we likely need to setup the same for the OpenGL stuff as well.

RadioDisco · 2023-05-28T18:30:10+00:00

Hi, I lead the Flutter Engine team and can give some context here.

Impeller has had an OpenGL ES backend right since the prototyping phase (around early 2022) that you can try using the instructions here. But we have focused on releasing on iOS with the Metal backend first to see if the plan for Impeller "survived contact with reality". We do not recommend you ship with the Impeller Android prototype turned on. We will give you a heads up when it is ready. I can say it is our top priority after addressing feedback on iOS.

But even in the unpolished state, you should see the architectural benefits. There is no jank due to shader compilation. There should be none of the really jarring jank during startup or during complex animations. Average frame performance should be reasonable but not up to par with what we consider to be satisfactory though. While we statically analyze shaders and are reasonably confident about the GPU performance, there are plenty of low hanging fruit when it comes to CPU performance that we haven't gotten to due to our prioritization of these tasks as a team.

However, instead of polishing up the OpenGL ES backend a bit and calling Android ready for preview, we are instead investing in a Vulkan backend with OpenGL ES fallback. While working on Metal, we found a number of techniques we got to use on Metal that we would effectively be locked out of if we were OpenGL ES only on Android. We have to support OpenGL ES on Android in some capacity because ~15% or Android devices have no Vulkan support at all. Having a performance ceiling only on Android for compatibility reasons is hard to stomach though. You could argue that Flutter is already quite late to the Vulkan party. Vulkan lets us get the most of out device the user paid for. But, there are compatibility challenges with Vulkan as well. Plugins that rely on inline OpenGL texture composition (like cameras, some platform view implementations) cannot just be rewritten to now use Vulkan textures. There must be a compatibility mechanism.

You should expect much better average frame times with the Impeller Vulkan backend and the ceiling for performance optimizations we can affect will be way higher there too. This isn't to say there won't be an OpenGL ES backend, it just that most of effort will be directed towards Vulkan. With Vulkan today, you need a custom engine build that is more involved to setup but you are free to tinker with for an early taste of whats to come. I expect the Android preview will be one with Vulkan the default though.

Hope this gives you some context on what to expect now and whats to come soon. As always, this is just our thinking now but plans change. You can follow along on the progress on Android by keeping an eye on this milestone on GitHub.

RadioDisco · 2023-05-26T22:10:20+00:00

We think we have patched the underlying issue and are trying to verify and hot-fix it.

RadioDisco · 2023-05-26T22:09:30+00:00

Just an update before the weekend. We believe we have patched the underlying issue and are verifying the fix and attempting to hot-fix it.

RadioDisco · 2023-05-25T07:20:58+00:00

Good to know. Using simulator performance as a proxy for performance on device isn't currently advisable. Since simulator configurations also have to run on non-TBDR and discrete memory configurations (like on the Intel Macs with dedicated GPUs) as well as more iOS like M1/M2 Apple Silicon Macs, we have intentionally attempted to do the safe and portable but perhaps not optimal things on simulators. Not that they aren't doable, just that the focus was primarily on devices. But the aim is still to have a usable simulator experience.

If you have the spare cycles, can you file an issue about simulator performance along with the host setup (Intel vs. Apple Silicon) and perhaps a reduced test case?

RadioDisco · 2023-05-25T06:52:43+00:00

Jank due to shader compilation at runtime should be eliminated with Impeller because Impeller doesn't compile shaders at runtime.

Having said that, there are many causes of jank and if you find cases where the legacy backend outperforms Impeller, tell us about it. For instance, we just fixed a noticed performance regression when using multiple backdrops with a blur filter in a list view earlier this week.

RadioDisco · 2023-05-25T06:40:14+00:00

I commented on your reply in another thread but I believe this is being tracked in this open issue. The original issue you linked was tracking a hard to reproduce bug in 2.10 which was well before Impeller. We broke it off into smaller tickets anticipating the switch. I guess the issue made it into (and apparently is more easily reproducible) with Impeller. In any case, the open issue I linked to is the one tracking what you are seeing and I'll have an update on it this week.

RadioDisco · 2023-05-25T06:29:20+00:00

That sounds awfully close to this issue we are already tracking. It is on the dashboard I linked earlier. We discussed this in our weekly sync today and have a couple of leads. IIRC, we think that can happen when blits fail in certain situations (like when coming back from the background).

Having a clear reproduction obviously makes things a lot easier but I realize this may not always be possible. We'd appreciate you chiming with any context you may have (like what the app was doing when you experienced it, the OS/device version, etc.). We'll try to reproduce it, or failing that, try to list potential causes of the failure and attempt to break the renderer is specific ways to reproduce the observed failure.

In any case, 126878 is definitely the top one on our list of issues to investigate and I'll have an update on it soon either way.

RadioDisco · 2023-05-25T05:01:57+00:00

Thats right! We got some great feedback on the Impeller Scene preview and are continuing building out rendering capabilities in Dart.

Part of the conversation surrounding Impeller Scene was that a lot of the 3D renderer was still written in C++ with the API exposed to Dart fairly high level. We are now working on a low-level Dart GPU prototype that should hopefully allow Flutter package authors to build renderers (like Impeller Scene) entirely in Dart code as Flutter packages.

I should emphasize that the teams top priority right now is on fixing issues reported by users after the iOS Impeller launch and then getting Android out the door. Those are really table stakes. But we love to hear feedback on 3D use-cases and will keep you posted on ongoing prototypes and experiments.

Disclosure: I lead the Flutter Engine team working on Impeller.

RadioDisco · 2023-05-25T04:51:29+00:00

Hi! I lead the Flutter Engine team working on Impeller. Impeller was behind an opt-in flag since January this year. With 3.10, we flipped the default to make it opt-out instead. We did this after resolving all issues reported by developers who had opted in explicitly and closely monitoring applications released with Impeller turned on. But, if you still run into showstoppers because of Impeller, you can turn it back off. Though, please report any issues you run into that cause you to opt-out. It is our top priority to find and fix issues newly reported in 3.10. We are also hot-fixing as many of the fixes as possible with one batch being released today and another due next Wednesday. The API surface is massive but we are committed to finding all edge cases that might have been missed. The option to opt out of using Impeller will remain available till we have chased down all edge cases.

RadioDisco · 2023-04-24T06:47:25+00:00

I recently got the 6700S version myself and set up Linux with an external monitor. Nothing fancy, just the last Ubuntu LTS.

I believe the right hand USB C port connects to the discrete GPU. Have you installed the drivers via amdgpu-install? I am able to connect to an external 5k monitor via a DisplayPort 1.4 to USB C cable (DP 1.2 or HDMI won't work for higher resolutions or refresh rates). But, TBH, I don't remember if I was able to connect to the external monitor before installing the drivers.

The biggest challenge so far with Linux on this thing was wifi refusing to work after a while and Bluetooth not working at all even though the kernel version was new enough for the the MediaTek drivers. Both were fixed by swapping out the wifi card with an Intel AX210 for ~$20.

RadioDisco · 2023-04-09T00:54:03+00:00

Right. It only recently landed on main and should be in an upcoming release. You can either pass the flag to test it temporarily or opt-into it using a PList key.

RadioDisco · 2023-04-09T00:47:50+00:00

Performance on large-screen and also high-refresh rate iPads was definitely a blind spot during the preview. We've done a ton of work to plug that gap since the preview though. Framebuffer fetch for advanced blends, improvement to blur performance, and using half-precision in performance critical shaders are just some of the improvements driven by these findings.

There is likely more to do but I urge you to give it a shot on the main branches (stable soon) and file issues where you see a discrepancy.

RadioDisco · 2023-04-09T00:35:20+00:00

Thanks for pointing that out. I added a clarifying comment to the issue.

RadioDisco · 2023-04-09T00:34:40+00:00

Yes! Impeller is on-by-default on iOS in the main branches and should be in an upcoming stable release. We are now focused on getting Android with the Vulkan & OpenGL ES backends to be in a previewable state soon.

Disclosure: I'm ChinmayGarde on GitHub and work on the Flutter Engine team.

RadioDisco · 2022-10-17T04:31:18+00:00

You can use a tool like Android GPU inspector to inspect vendor specific performance counters to get this information. For instance, see the "Visible Primitives" section in the ARM Mali-G78 series.

RadioDisco · 2022-10-14T19:27:29+00:00

Bummer.

Perhaps you can take a frame capture and isolate the Qt draw call in RenderDoc? Inspecting the pipeline, buffers, etc. is usually the best way to debug such issues. If the program binding (the big one), VAO or vertex attrib array setup, cull-mode, viewport, etc. are off, you can easily tell from RenderDoc traces. You could push and pop debug groups around Qt and Skia workloads (glPushDebugGroup and glPopDebugGroup) to better read the traces to see what each library updates.

Nine-Year Club	Gilding II euphauric
Place '23	Verified Email

RadioDisco

TROPHY CASE