Stop using deprecated compositing paths
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Oxide |
Fix Released
|
High
|
Chris Coulson |
Bug Description
The 2 compositing paths we were previously using have been removed from Chromium. As an interim, we are now using 2 other compositing paths (software compositing mode or mailbox compositing mode). However, both of these will eventually be removed in favour of the delegated renderer.
Longer term, we want to hook the delegated renderer path in to the QML scenegraph compositor so that we have a single compositor. However, as an interim solution we could run a single-threaded browser-side compositor for each webview (IIUC, this is how ContentViewCore and ContentViewRend
Changed in oxide: | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in oxide: | |
milestone: | none → branch-1.2 |
assignee: | nobody → Chris Coulson (chrisccoulson) |
Changed in oxide: | |
status: | In Progress → Fix Released |
milestone: | branch-1.2 → branch-1.1 |
https:/ /code.launchpad .net/~chrisccou lson/oxide/ rendering- updates contains the initial work for this, which puts a synchronous compositor on the browser side in between the delegated renderer compositor and QML scenegraph compositor. This gets us off the obsolete rendering paths in Chrome, although I'd still like to eventually delegate all of this to the QML scenegraph compositor. The extra compositor would then only be required for the fallback case (where there is no shared GL context provided by the application)