[Impeller][Windows] Significantly slower startup compared to Skia

### Steps to reproduce

**Steps to reproduce**

1. Use Flutter 3.47.1 stable
2. Clone the minimal reproduction project: https://github.com/EgorKoschel/flutter_impeller_windows_test
3. Run the application in release mode with the default Impeller renderer:
`flutter run -d windows --release`
4. Observe the startup timing output.
5. In windows/runner/main.cpp, uncomment the following line to disable Impeller and use Skia:
`project.set_impeller_switch(flutter::ImpellerSwitch::Disabled);`
6. Run exactly the same command again:
`flutter run -d windows --release`
7. Compare the startup timings.

The project is a minimal Windows-only Flutter application without third-party dependencies or application-specific initialization.

With Impeller enabled, almost all of the additional startup time is spent while constructing `flutter::FlutterViewController`, before plugin registration.

**Impeller**
```
[STARTUP] DartProject created: 1 ms
[STARTUP] Win32Window OnCreate completed: 3 ms
[STARTUP] Before FlutterViewController: 3 ms
[IMPORTANT:flutter/shell/platform/embedder/embedder_surface_gl_impeller.cc(126)] Using the Impeller rendering backend (OpenGLESSDF).
[STARTUP] FlutterViewController created: 1186 ms
[STARTUP] Plugins registered: 1186 ms
[STARTUP] Flutter view attached: 1190 ms
[STARTUP] Window/Create completed: 1190 ms
[STARTUP] First Flutter frame: 1232 ms
```

**Skia**
```
[STARTUP] DartProject created: 1 ms
[STARTUP] Win32Window OnCreate completed: 4 ms
[STARTUP] Before FlutterViewController: 4 ms
[STARTUP] FlutterViewController created: 58 ms
[STARTUP] Plugins registered: 58 ms
[STARTUP] Flutter view attached: 69 ms
[STARTUP] Window/Create completed: 69 ms
[STARTUP] First Flutter frame: 165 ms
```

The FlutterViewController constructor therefore takes approximately:

- Impeller: 1183 ms
- Skia: 54 ms

The time to the first Flutter frame is approximately:

- Impeller: 1232 ms
- Skia: 165 ms

I repeated the test multiple times with both renderers. The results were consistent across repeated launches: Impeller consistently spent roughly 1 second or more constructing FlutterViewController, while Skia completed the same step in only a few dozen milliseconds. The large difference was reproducible and was not limited to the first launch.

**Main channel**

The issue is also reproducible on the current Flutter main channel, although the performance characteristics are different from Flutter 3.47.1 stable.

**Impeller**
```
[STARTUP] DartProject created: 1 ms
[STARTUP] Win32Window OnCreate completed: 3 ms
[STARTUP] Before FlutterViewController: 3 ms
[IMPORTANT:flutter/shell/platform/embedder/embedder_surface_gl_impeller.cc(127)] Using the Impeller rendering backend (OpenGLESSDF).
[STARTUP] FlutterViewController created: 101 ms
[STARTUP] Plugins registered: 101 ms
[STARTUP] Flutter view attached: 113 ms
[STARTUP] Window/Create completed: 113 ms
[STARTUP] First Flutter frame: 618 ms
```
**Skia**
```
[STARTUP] DartProject created: 1 ms
[STARTUP] Win32Window OnCreate completed: 3 ms
[STARTUP] Before FlutterViewController: 3 ms
[STARTUP] FlutterViewController created: 47 ms
[STARTUP] Plugins registered: 47 ms
[STARTUP] Flutter view attached: 55 ms
[STARTUP] Window/Create completed: 55 ms
[STARTUP] First Flutter frame: 134 ms
```

On the main channel, FlutterViewController creation is significantly faster than on Flutter 3.47.1 stable. However, startup with Impeller is still substantially slower overall.

Time to first Flutter frame:

- Impeller: 618 ms
- Skia: 134 ms

Impeller therefore takes approximately 4.6x longer to reach the first Flutter frame in this run.

On Flutter 3.47.1 stable, most of the delay occurs while constructing FlutterViewController. On the current main channel, that part has improved substantially, but a significant startup delay remains after FlutterViewController has been created and before the first Flutter frame is rendered.

### Code sample

Minimal reproduction:

https://github.com/EgorKoschel/flutter_impeller_windows_test

The relevant timing instrumentation is placed immediately around the FlutterViewController constructor:

```
PrintStartupTime("Before FlutterViewController");

flutter_controller_ = std::make_unique(
frame.right - frame.left,
frame.bottom - frame.top,
project_);

PrintStartupTime("FlutterViewController created");
```

Impeller is enabled by default.

For comparison with Skia, the reproduction project contains the following commented-out line in `windows/runner/main.cpp`:

```
flutter::DartProject project(L"data");

// Uncomment to disable Impeller and use Skia.
// project.set_impeller_switch(flutter::ImpellerSwitch::Disabled);
```

No other code is changed between the Impeller and Skia measurements.

### Performance profiling on master channel

- [x] The issue still persists on the master channel

### Timeline Traces

The observed delay occurs during native Windows engine initialization, inside the flutter::FlutterViewController constructor and before plugin registration or the first Flutter frame.

The C++ timing instrumentation in the reproduction project was used to isolate this native startup delay.

### Video demonstration

### What target platforms are you seeing this bug on?

Windows

### OS/Browser name and version | Device information

Windows 11 Pro 25H2, x64
OS build: 26200

GPU: Intel(R) UHD Graphics 770
GPU driver version: 32.0.101.7088
GPU driver date: 2026-06-17

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

Unknown

### Is the problem only reproducible with Impeller?

Yes

### Logs

### Flutter Doctor output

[√] Flutter (Channel stable, 3.47.1, on Microsoft Windows [Version 10.0.26200.9168], locale de-DE) [233ms]
• Flutter version 3.47.1 on channel stable at C:\src\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 6655482ec0 (8 days ago), 2026-08-19 10:07:23 -0700
• Engine revision 5d53178869
• Dart version 3.13.1
• DevTools version 2.60.0
• Feature flags: enable-web, enable-linux-desktop, enable-macos-desktop, enable-windows-desktop, enable-android, enable-ios, cli-animations, enable-native-assets, enable-record-use, enable-swift-package-manager, omit-legacy-version-file, enable-lldb-debugging, enable-uiscene-migration

[√] Windows Version (11 Pro 64-bit, 25H2, 2009) [1.253ms]

[√] Android toolchain - develop for Android devices (Android SDK version 36.0.0) [1.466ms]
• Android SDK at C:\Users\EgorKoschel\AppData\Local\Android\sdk
• Emulator version 35.4.9.0 (build_id 13025442) (CL:N/A)
• Platform android-36, build-tools 36.0.0
• Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
This is the JDK bundled with the latest Android Studio installation on this machine.
To manually set the JDK path, use: `flutter config --jdk-dir="path/to/jdk"`.
• Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-9586694)
• All Android licenses accepted.

[√] Chrome - develop for the web [60ms]
• Chrome at C:\Users\EgorKoschel\AppData\Local\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.6.5) [59ms]
• Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
• Visual Studio Community 2022 version 17.6.33829.357
• Windows 10 SDK version 10.0.22000.0

[√] Connected device (3 available) [139ms]
• Windows (desktop) • windows • windows-x64 • Microsoft Windows [Version 10.0.26200.9168]
• Chrome (web) • chrome • web-javascript • Google Chrome 151.0.7922.174
• Edge (web) • edge • web-javascript • Microsoft Edge 151.0.4129.107

[√] Network resources [362ms]
• All expected network resources are available.

• No issues found!

Start with the minimal reproduction project and its timing instrumentation around the FlutterViewController constructor in windows/runner/main.cpp. Run the release-mode comparison with Impeller enabled and disabled, then profile the native Windows startup path to isolate the remaining delay before the first Flutter frame. Done means identifying and addressing the Impeller-specific startup cost while preserving the reported renderer behavior.

Written by the indexing model from the issue text.