3 ms·

The reason why Chrome and Electron still need a flag is simple: Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as

by jchw 4y ago

The reason why Chrome and Electron still need a flag is simple: Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11. They had a lot of false starts: it took years before Wayland support actually got upstreamed in any regard. Likewise for Electron. It does generally work to the point of daily-driver usability today with stable Chrome and Electron, but some apps are shipping old and out-of-support versions of Electron, so unfortunately it has become a bit of a waiting game. Anyways, you can't actually do proper DPI virtualization for X11 apps because afaik there is no protocol for apps to communicate the scale that they are actually rendering at, so there will never be full support for mixed or fractional DPI in XWayland to the same degree that it is supported in Wayland. I'm not 100% sure there would be a point to making such a protocol at this point, since blurry-but-correct surfaces seems like an OK trade-off to keep things working in the long term. If you run real X11 with mixed DPI or fractional DPI, you get quite a range of potential failure cases depending on what apps you run. At this point most of my screen is filled with native Wayland apps, and Electron apps that use reasonably up-to-date Electron (like VS Code), so it's rare to see a blurry window.

yjftsjthsd-h 4y ago
> Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11. I'm not doubting you, but given that ChromeOS uses Wayland I'm very confused by this.
- Karellen 4y ago
  I'm not familiar with the situation, but my guess would be that ChromeOS has created its own Wayland compositor with a bunch of private protocol extensions that Chrome on ChromeOS uses to get stuff done. But for some reason or another, those protocol extensions are not suitable for submitting as new public extensions for other compositors to implement. Or they are suitable for submission, but the official extension roadmap already has different extensions in the works (but not yet complete) that will do the same thing.
  - jchw 4y ago
    Yep, ChromeOS basically has Chrome itself as the compositor, so it doesn't have to worry about running "under" Wayland at all. Take a look at the "blocked on" to see the kinds of things still remaining: https://bugs.chromium.org/p/chromium/issues/detail?id=578890 https://bugs.chromium.org/p/chromium/issues/detail?id=578890
- Jasper_ 4y ago
  ChromeOS uses Wayland as a bridge between Android and Chrome because it's a politically neutral technology neither of them control, and thus can both agree on implementing. It's not about integrating better with other Wayland compositors or the wider Wayland/Linux ecosystem, it's about using Wayland as a piece of technology to sling buffers back and forth between two different camps who are otherwise on bad terms. ChromeOS implements a Wayland compositor to support Android apps running as Wayland clients. Chrome being a well-behaved Wayland client is something completely different.
nubinetwork 4y ago
> Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11 Do you have any examples? I used ms teams in chrome yesterday, and it seemed to work fine with webcam and screen sharing.
- Too 4y ago
  Everybody using MS Teams on a modern Linux distro must have enabled this option at some point. Otherwise you can’t screen share. Given the recent 3 years since pandemic, that should provided ample of time and test data for stabilization.
- jchw 4y ago
  Upstream Chrome bugs are here: https://bugs.chromium.org/p/chromium/issues/detail?id=578890 https://bugs.chromium.org/p/chromium/issues/detail?id=578890 Electron has different issues it's been working on, though. I believe it has some issues with window border rendering in some cases as well as issues with cursor size on fractional scale.
  - nubinetwork 4y ago
    Thankfully most of those are closed... maybe if we're lucky we'll see official support this year.

by jchw 4y ago

yjftsjthsd-h 4y ago

> Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11. I'm not doubting you, but given that ChromeOS uses Wayland I'm very confused by this.

Karellen 4y ago
I'm not familiar with the situation, but my guess would be that ChromeOS has created its own Wayland compositor with a bunch of private protocol extensions that Chrome on ChromeOS uses to get stuff done. But for some reason or another, those protocol extensions are not suitable for submitting as new public extensions for other compositors to implement. Or they are suitable for submission, but the official extension roadmap already has different extensions in the works (but not yet complete) that will do the same thing.
- jchw 4y ago
  Yep, ChromeOS basically has Chrome itself as the compositor, so it doesn't have to worry about running "under" Wayland at all. Take a look at the "blocked on" to see the kinds of things still remaining: https://bugs.chromium.org/p/chromium/issues/detail?id=578890 https://bugs.chromium.org/p/chromium/issues/detail?id=578890
Jasper_ 4y ago
ChromeOS uses Wayland as a bridge between Android and Chrome because it's a politically neutral technology neither of them control, and thus can both agree on implementing. It's not about integrating better with other Wayland compositors or the wider Wayland/Linux ecosystem, it's about using Wayland as a piece of technology to sling buffers back and forth between two different camps who are otherwise on bad terms. ChromeOS implements a Wayland compositor to support Android apps running as Wayland clients. Chrome being a well-behaved Wayland client is something completely different.

nubinetwork 4y ago

> Chrome still has a decent chunk of work to do before Wayland is supported to the same degree as X11 Do you have any examples? I used ms teams in chrome yesterday, and it seemed to work fine with webcam and screen sharing.

Too 4y ago
Everybody using MS Teams on a modern Linux distro must have enabled this option at some point. Otherwise you can’t screen share. Given the recent 3 years since pandemic, that should provided ample of time and test data for stabilization.
jchw 4y ago
Upstream Chrome bugs are here: https://bugs.chromium.org/p/chromium/issues/detail?id=578890 https://bugs.chromium.org/p/chromium/issues/detail?id=578890 Electron has different issues it's been working on, though. I believe it has some issues with window border rendering in some cases as well as issues with cursor size on fractional scale.
- nubinetwork 4y ago
  Thankfully most of those are closed... maybe if we're lucky we'll see official support this year.