← Back to team overview

ubuntu-webapps-bugs team mailing list archive

[Bug 1426153] [NEW] Use a single threaded webview compositor

 

Public bug reported:

The webview compositor currently runs on a separate thread - it's like
this because at one stage it looked like Google were going to remove the
single threaded mode. However, they seem to have settled on a single-
threaded browser compositor for now.

A threaded webview compositor has always been unnecessary in Oxide for a few reasons:
- It doesn't handle any animations, so there are no cases where it needs to remain responsive if the main thread is blocked.
- It only contains a single visible layer - the delegated frame layer. Updating this involves the main thread anyway.
- Unlike the renderer main thread which runs arbitrary script, what runs on the browser main thread is controlled by the embedder and predictable. The browser main thread should never be busy enough to block the compositor.
- It adds unnecessary complexity.
- It introduces additional thread hops.

** Affects: oxide
     Importance: High
         Status: Triaged

** Changed in: oxide
   Importance: Undecided => High

** Changed in: oxide
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1426153

Title:
  Use a single threaded webview compositor

Status in Oxide Webview:
  Triaged

Bug description:
  The webview compositor currently runs on a separate thread - it's like
  this because at one stage it looked like Google were going to remove
  the single threaded mode. However, they seem to have settled on a
  single-threaded browser compositor for now.

  A threaded webview compositor has always been unnecessary in Oxide for a few reasons:
  - It doesn't handle any animations, so there are no cases where it needs to remain responsive if the main thread is blocked.
  - It only contains a single visible layer - the delegated frame layer. Updating this involves the main thread anyway.
  - Unlike the renderer main thread which runs arbitrary script, what runs on the browser main thread is controlled by the embedder and predictable. The browser main thread should never be busy enough to block the compositor.
  - It adds unnecessary complexity.
  - It introduces additional thread hops.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1426153/+subscriptions


Follow ups

References