在将于2021年发布的Chromium中，您期望发生什么变化？

这些更改将使Chromium和许多其他Chromium /应用程序更易于使用！在2019年，我第一次尝试为WebRTC的内容做出贡献。

所有这些内容都是为了支持dg-desktop-portal和LinuxWayland上有关屏幕共享信息的PipeWire。

当时，我们面临的情况非常简单，我们只有PipeWire0.2，并且所有门户后端仅支持屏幕共享（不支持窗口共享）。

尽管这相对容易，但是由于每个屏幕共享请求都涉及两个门户网站对话框来获取网页本身的屏幕内容，因此并不理想。

对我来说，这是巨大的成功，因为我为如此之大的项目做出了非常重要的贡献，这一项目被许多人使用，并被所有现代浏览器所使用。

在2020年初，也就是每个人都希望从内存中删除此内存的那一年，我们得到了PipeWire0.3（API稍有不同），后来有了xdg-desktop-portal-gtk和xdg-desktop -portal-kde（今年晚些时候）人们最终将能够共享应用程序窗口。

WebRTC缺少对所有这些功能的支持，因为那时这些功能不可用。

我想立即解决所有问题，为窗口共享提供支持，并摆脱“对话”。

门户网站的功能，门户网站后端的新窗口共享功能更加糟糕。

总体情况如上图所示。

每次您请求共享屏幕时，Chromium都会显示一个预览对话框。

该对话框包括三页。

一页用于屏幕共享以发出门户请求，第二页用于窗口共享，这是另一个门户请求，最后一页用于允许共享打开的网页。

您必须确认两个门户对话框，然后确认Chromium对话框，最后您将获得另一个门户对话框，以获取网页本身的内容。

我有一个解决方案。

我为所有门户网站调用使用了一个ID，并在Chromium预览对话框的两页之间以及对网页本身的请求中与Chromium共享了此ID（门户电话）。

使用此解决方案，我们只有一个门户对话框。

这是一个完美的解决方案（至少看起来是这样）。

我从今年年初开始研究此问题。

我们与ChromiumUX小组的人员交换了很多电子邮件，因为我还想尝试在预览对话框中进行一些小的UI更改。

不幸的是，为了保持与所有平台的一致性，这些请求被拒绝了。

但这没什么大不了的，我提交了更改以供审核，并保持UI不变，只是将所有必需的部分添加到Chromium和WebRTC中以使其正常工作。

我想说的是，尽管自那时以来似乎一切顺利，但事实恰恰相反。

尽管我花了一些时间阅读所有内容，但是许多人在令人满意的条件下在家工作并不奇怪。

无论如何，都已经过去了几个月，而我最终甚至在没有时间计算花费在它上面的时间之前，重写了很多次更改。

这一切使我沉迷于这种变化。

我一直在思考如何做得更好，而且我经常在晚上解决一些问题，而不是花时间陪伴家人。

最好在我心爱的Playstation上浪费时间。

这对我的心理健康产生了非常不利的影响。

我意识到必须停止这种情况，所以我只是放弃了，因为我不能再这样下去了，我需要休息一下。

我放弃了两项更改（WebRTC和Chromium），并决定仅选择我能够进行的更改。

我所做的更改可能过于雄心勃勃且过于复杂，或者可能是Chromium尚未准备好接受此更改，因为某些调整是针对我的用例的。

我不希望上游开发人员能给我更多帮助，因为关于Wayland，门户网站和PipeWire以及如何将它们集成在一起，还有很多要了解的地方。

无论如何，我都有一个新的起点。

放弃更改后，我没有压力，我选择了最重要的更改并分别提交。

现在让我感到惊讶的是，事情进展得如此顺利，而这些更改的上传速度如此之快。

这些更改简单，易于理解且易于查看。

我没有完全放弃解决“对话”的问题。

问题。

我还有其他想法，但是下次我将尝试逐步提交它们，而不会占用过多的空闲时间。

在将于2021年发布的Chromium中，您期望发生什么变化？支持PipeWire0.3现在，您可以使用PipeWire0.2和PipeWire0.3来构建Chromium / WebRTC。

有一个新的“ rtc_pipewire_version”可以传递给构建配置的选项。

可能不需要描述对此的窗口共享支持。

如果您不想共享整个屏幕，则可以共享应用程序窗口。

支持DmaBuf和MemFd缓冲区类型。