[Impeller] Use the IO context for OpenGL program setup

[xiaowei-guan]

Impeller eagerly sets up the entire set of pipeline state objects (PSOs) it may need during renderer setup. This works fine on mid to high-end devices as the setup completes well before the first frame is rendered.

However on low-end devices, not all PSOs may be ready before the first frame is rendered. Low-end device usually don't have as much available concurrency and are slower to boot. On these devices, the rendering thread had to wait for the background compile job to be completed. It was also observed that the relatively higher priority render thread was waiting on a background thread to finish a PSO compile job. The PSO compile job could also be stuck behind another job that was not immediately needed. This made the situation on low end devices less than ideal.

flutter#180022, this PR fix PSO stuck issue for Vulkan on low end devices.
Current PR can fix the PSO stuck issue for GLES on low end devices. Related issue : flutter#176657

This PR can improve app startup time for impeller+GLES on low-end devices.
flutter#180022 has provided solution for impeller + vulkan.

Impeller+GLES has a special case: resource loading cannot be arbitrarily placed on other threads; it needs to be done on the I/O thread because this thread shares the context with the GPU thread. Therefore, this PR introduces the I/O task runner into PipelineCompileQueueGLES. However, since the I/O task runner may handle other tasks, we cannot put all jobs into the I/O thread at once. My current solution is to wait for the previous job to finish before putting the next one into the I/O thread.

Main changes:

Introduce fml::RefPtrfml::TaskRunner into PipelineCompileQueueGLES.
Extract new class PipelineCompileQueueVulkan for vulkan, because the runners are on different threads.

[gemini-code-assist]

Code Review

This pull request refactors PipelineCompileQueue into an abstract base class and introduces backend-specific subclasses, PipelineCompileQueueGLES and PipelineCompileQueueVulkan, to handle pipeline compilation scheduling. It also updates GLES context creation and platform views to pass an IO task runner. Feedback on these changes highlights that the abstract PipelineCompileQueue still declares an unimplemented static Create method and constructor, which should be removed. Additionally, a null check for the task runner should be added to PipelineCompileQueueVulkan::Create along with a corresponding unit test, and the mutex lock scope in PipelineCompileQueueGLES::OnJobAdded should be minimized to prevent potential deadlocks when calling external functions.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Minimize the scope of processing_mutex_ in OnJobAdded so that the lock is not held while calling DrainPendingJobs(). DrainPendingJobs() eventually calls PostJob(), which is a pure virtual function calling into the task runner. Calling virtual/external functions while holding a lock is a known deadlock risk and should be avoided.

void PipelineCompileQueueGLES::OnJobAdded() {
  bool should_drain = false;
  {
    Lock lock(processing_mutex_);
    if (!is_processing_) {
      is_processing_ = true;
      should_drain = true;
    }
  }
  if (should_drain) {
    DrainPendingJobs();
  }
}

[gemini-code-assist]

Code Review

This pull request refactors PipelineCompileQueue into a base class and introduces backend-specific implementations, PipelineCompileQueueGLES and PipelineCompileQueueVulkan, along with corresponding unit tests. It updates ContextGLES and PipelineLibraryGLES to accept and utilize an IO task runner for scheduling pipeline compilation. Feedback on these changes identifies that the asynchronous pipeline generation task in PipelineLibraryGLES does not synchronize with the GPU thread, potentially flooding the reactor queue and defeating the purpose of the compile queue. Additionally, a missing null check for the worker task runner in PipelineCompileQueueVulkan::Create could lead to a null pointer dereference.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The generation_task is completely asynchronous because it only calls reactor->AddOperation (which is non-blocking) and returns immediately. As a result, PipelineCompileQueueGLES::DrainPendingJobs will continuously and immediately post all pending compilation tasks to the GPU thread's reactor queue without waiting for the actual compilation (CreatePipeline) to complete.

This defeats the purpose of the compile queue, as the GPU thread will still be flooded with all compilation tasks at once, causing the same startup jank/blocking issues on low-end devices.

To fix this, we should synchronize the IO thread and the GPU thread so that the next compilation task is only posted after the current one has finished compiling on the GPU thread. We can achieve this by using a synchronization primitive like fml::AutoResetWaitableEvent inside generation_task to wait for the reactor operation to complete. We must only wait when running asynchronously to avoid deadlocks when running synchronously on the GPU thread.

Note: You will also need to include #include "flutter/fml/synchronization/waitable_event.h" in this file.

  auto weak_this = weak_from_this();
  auto reactor = reactor_;
  auto generation_task = [promise, weak_this, descriptor, vert_function,
                          frag_function, threadsafe, reactor](std::shared_ptr<fml::AutoResetWaitableEvent> compilation_completed) {
    auto thiz = weak_this.lock();
    if (!thiz) {
      promise->set_value(nullptr);
      if (compilation_completed) {
        compilation_completed->Signal();
      }
      return;
    }
    const auto result = reactor->AddOperation([promise,        //
                                               weak_this,      //
                                               descriptor,     //
                                               vert_function,  //
                                               frag_function,  //
                                               threadsafe,     //
                                               compilation_completed
    ](const ReactorGLES& reactor) {
      promise->set_value(CreatePipeline(weak_this, descriptor, vert_function,
                                        frag_function, threadsafe));
      if (compilation_completed) {
        compilation_completed->Signal();
      }
    });
    if (!result) {
      promise->set_value(nullptr);
      if (compilation_completed) {
        compilation_completed->Signal();
      }
    }
    FML_CHECK(result);
    if (compilation_completed) {
      compilation_completed->Wait();
    }
  };

  if (async && compile_queue_) {
    auto compilation_completed = std::make_shared<fml::AutoResetWaitableEvent>();
    compile_queue_->PostJobForDescriptor(descriptor, [generation_task, compilation_completed]() {
      generation_task(compilation_completed);
    });
  } else {
    generation_task(nullptr);
  }