[Android] Periodic frame rate drops (60→54 FPS; 6-10 consecutive frames c. every 5 seconds) with CoreCLR on .NET 11 — regression from Mono on .NET 10

[janne-hmp]

Description

We are developing a real-time roguelike game (GnollHack) using .NET MAUI with SkiaSharp (SKGLView) for rendering on Android. The game targets 60 FPS and achieves this consistently on .NET 10 with the Mono runtime.

As per the post by @davidortinau last week, we tested .NET MAUI 11 Preview 6 on Android to see how it compares with Mono Runtime in .NET 10. After upgrading to .NET 11 Preview 6+ (which uses CoreCLR exclusively on Android), we observe periodic (every 5 seconds or so) frame rate drops from 60 FPS to approximately 50–54 FPS (6-10 consecutive frames drop every 5 seconds or so), causing severe stutters in the game and making the game to feel continuously very jerky. These drops occur at regular intervals regardless of scene complexity, even on screens with very little drawing. The drops are clearly visible as jerkiness/microstutters during gameplay.

This appears to be a performance regression introduced by the Mono → CoreCLR transition on Android.

If @jfversluis or @jonathanpeppers or someone else already know a solution working for this in .NET MAUI 11, please let me know.

Expected Behavior

Consistent 60 FPS rendering, matching .NET 10 (Mono) performance.

Actual Behavior

Frame rate periodically drops to 50–54 FPS at regular intervals, causing visible jerkiness. The drops occur:

• From the very start of the application
• Regardless of scene complexity (even with minimal drawing)
• At consistent, periodic intervals

Attempted Mitigations (none helped)

Setting	Result
DOTNET_TieredCompilation=0	No improvement
DOTNET_GCGen0MaxBudget=8000000 (128 MB)	No improvement
DOTNET_gcServer=0 (Workstation GC)	No improvement
Default CoreCLR settings (no tuning)	Same periodic drops

Steps to Reproduce

1. Create a .NET MAUI application targeting net11.0-android with a SkiaSharp SKGLView rendering at 60 FPS.
2. Build and deploy to an Android device.
3. Observe periodic frame rate drops from 60 to ~54 FPS at regular intervals.
4. Compare with the same application targeting net10.0-android (Mono runtime) — no such drops occur.

Environment

• .NET SDK: 11.0.100-preview.6 (or later)
• Runtime: CoreCLR (Mono no longer available in Preview 6+)
• Platform: Android (arm64)
• Rendering: SkiaSharp SKGLView (OpenGL ES)
• Target FPS: 60
• Device: (Insert your test device and Android version here)
• Comparison baseline: .NET 10 with Mono runtime — consistent 60 FPS, no drops

Additional Context

• The application is a complex roguelike game with native C libraries linked via P/Invoke, FMOD audio, and multi-layer tile rendering.
• The frame drops are not correlated with scene complexity, suggesting the cause is runtime-level periodic work (GC, thread pool, diagnostics, or other background activity) rather than application code.
• We also encountered a separate issue where DOTNET_DiagnosticPorts in Environment.txt (previously used for Mono debugging) caused the CoreCLR runtime to suspend at startup and never resume. Removing it fixed that issue, but the periodic FPS drops remain.
• <UseMonoRuntime>true</UseMonoRuntime> is no longer supported in .NET 11 Preview 6+, so we cannot fall back to Mono to verify the regression on the same SDK version.

[janne-hmp]

I made a test app to show the periodic drop in FPS: https://github.com/hyvanmielenpelit/Net11FPSBenchmark Here it happens, every 10 to 20 s or so. It has various extra switches to test things, and also the iOS issue separately, but it currently best works for demonstrating this problem on Android. There is also a script to alternate between .NET 10 and .NET 11. In .NET 10 you can observe a much smoother FPS behavior.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[steveisok]

Could be something in the GC bridge. dotnet/android#11567 seems to be showing something similar.

[steveisok]

I was curious so I did some analysis:

Reproduced with a small Android probe: a frame-pacing harness that runs two modes allocating the same number of objects and bytes each frame. The only difference is that one mode gives each object a Java peer and the other doesn't. The no-peer mode is the control — if frames drop there too, the cause is allocation, not the bridge.

Mechanism. When a .NET object is paired with a Java object, neither runtime can free its side alone — they have to compare notes. So whenever a .NET GC finds even one such pair where the .NET side is dead, it asks Android to run a Java GC to check whether the Java side is dead too. That request is unthrottled, so a gen0 collection is enough to trigger a full ART collection.

The problem isn't the ART collection itself — it's what it does to the UI thread. Drawing a frame creates Java objects, and creating one takes a lock that the running ART collection holds for long stretches. So the UI thread sleeps ~15 ms at a time and misses its frame deadline.

Perfetto and simpleperf confirm each step: every stall (60/60) lands inside an ART collection; the same managed work costs 39.4 ms during one vs 1.30 ms outside (~30×); and 80.6% of the UI thread's waiting is in art::JavaVMExt::AddGlobalRef — the lock in question. The control mode shows none of this, so it's the bridge, not the allocation.

On the regression framing. Mono also drops frames (60 → ~57). It fires ~2× more explicit GCs (396 vs 212) yet loses ~4× less time (283 ms vs 1175 ms per 5 s) — so per-event cost dominates, not trigger frequency.

Suggested fixes — runtime side. Two, both prototyped and passing the existing GCBridge test:

1. Skip the Tarjan/SCC pass when the client is still processing a previous set — the VM already discards those args, so the work is wasted. Behavior-neutral.
2. Throttle how often new requests are produced (e.g. System.GC.BridgeMinIntervalMs, default 50 ms), gen0 only — bridge objects are force-promoted regardless, so leaving gen1+ unthrottled bounds retention to the next gen1 GC.

Suggested fix — dotnet/android side. GCBridge::trigger_java_gc calls Runtime.gc() unconditionally on every bridge request, with no rate limiting or coalescing. Since the request is advisory, a minimum interval or a "skip if a collection just ran" check there would cut trigger rate independently of the runtime change — and it's the layer that can see how recently ART actually collected. Worth considering whether every request needs a full explicit collection at all.

Since per-event cost dominates, the bigger win is likely reducing what the UI thread contends on during a collection, which is also dotnet/android territory. I haven't measured either of these, unlike the runtime-side changes.

Numbers are from an emulator (understates cost); any throttle default would need tuning on real arm64.

Ruled out: WeakReference.Target bridge blocking is not a contributor (measured, indistinguishable from strong refs). Also, debug.mono.log=gc,gref fabricates this bug via logcat volume — don't measure with it on.

Note

This analysis was generated with GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to this area: @anicka-net, @dotnet/gc
See info in area-owners.md if you want to be subscribed.