cobalt: Move VideoGeometrySetterService on gpu thread

[borongc]

Relocate the VideoGeometrySetterService from the browser process to
the GPU process. This change instantiates the service within the
CobaltContentGpuClient, allowing it to be managed directly on the GPU
thread.

This improves performance and reduces IPC overhead for video geometry
updates by co-locating the service closer to the GPU and compositing
operations. The StarboardRendererWrapper now directly subscribes to
video geometry changes from this local service.

Mojo communications:

• Before: viz (gpu) --> browser thread --> StarboardRendererClient (media) --> StarboardRendererWrapper (gpu)
• After: viz (gpu) --> StarboardRendererWrapper (gpu)

Note this is called nearly per UI frame update.

Issue: 405424096

[github-actions]

🤖 Gemini Suggested Commit Message

---

cobalt: Move VideoGeometrySetterService to GPU

Relocate the VideoGeometrySetterService from the browser process to
the GPU process. This change instantiates the service within the
CobaltContentGpuClient, allowing it to be managed directly on the GPU
thread.

This improves performance and reduces IPC overhead for video geometry
updates by co-locating the service closer to the GPU and compositing
operations. The StarboardRendererWrapper now directly subscribes to
video geometry changes from this local service.

Bug: 405424096

---

💡 Pro Tips for a Better Commit Message:

1. Influence the Result: Want to change the output? You can write custom prompts or instructions directly in the Pull Request description. The model uses that text to generate the message.
2. Re-run the Generator: Post a comment with: /generate-commit-message

[gemini-code-assist]

Code Review

This pull request successfully moves the VideoGeometrySetterService from the browser process to the GPU process, which should improve performance by reducing IPC overhead. The changes are logical and follow the description. I've found a few areas for improvement: a duplicate dependency, a simplification in a constructor, and a potential behavioral change in how video geometry is calculated that should be reviewed.

[sideb0ard]

This looks great. Do we have any measurement to show the difference in performance and IPC overhead?

[borongc]

This looks great. Do we have any measurement to show the difference in performance and IPC overhead?

Latency Breakdown

The "1ms savings" comes from the elimination of the cross-process IPC hop from the Compositor to the Browser.

End-to-End Latency Comparison

• Before Commit: ~2.5 ms
  • Hop 1 (viz ➡️ Browser): ~1.0 ms to 1.5 ms (Standard Chromium IPC overhead)
  • Hop 2 (Browser ➡️ Media): 1.21 ms (Time waiting on Browser Main thread)
• After Commit: 1.71 ms
  • Hop 1 (viz ➡️ GPU): 0 ms (Eliminated)
  • Hop 2 (GPU ➡️ Media): 1.71 ms (Direct cross-thread routing)

Jitter & Stability

• Before Max Jitter: 20.22 ms (Updates frequently arrived >16.6ms late, missing frame windows).
• After Max Jitter: 17.13 ms (Reduced by >3ms).

Conclusion

By moving the service to the GPU process, the architecture effectively saved ~1ms of average latency per frame. More importantly, it removed the dependency on the Browser UI thread, preventing frames from arriving late due to UI-related processing spikes.

[Awallky]

Would it be possible to set up a cobalt-specific subclasses of content_gpu_client and gpu_service_factory?
It would make future rebases a bit easier in the future if we just subclass them instead of adding to the content layer.

[borongc]

Would it be possible to set up a cobalt-specific subclasses of content_gpu_client and gpu_service_factory?

Probably it's not easy as Chromium core code path has this function. Let me know if you think there is a better way to do this.