沉寂 2 年多的 xwidget 迎来了 Po Lu 大神的大量更新

最近 Emacs Master 分支提交了大量来自 Po Lu 大神的 xwidget 更新,很值得期待,比如:

  1. GStreamer xwidget

  1. Add command to browse xwidget history
  2. New function for explictly killing xwidgets
  3. Add xwidget-webkit-isearch-yank-kill
7 个赞

这次最显著的效果就是,解决了以前的闪烁问题

这个特性会不会默认打开哦

主要是这个补丁 http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=61d049aaff2ede48d3d4b357bc1cb06447f15229

用x11来绘制

前一段时间看邮件列表讨论,有的开发者认为xwidget的路线是条死路,Po Lo 大神不认为,所以近期一直再修复,改进了许多,我的观点是,只要它不闪烁,就有价值,做做预览等功能也不错。

我感觉这个方式类似eaf的黏窗口,但只是猜测,不懂细节。

1 个赞

不是粘贴窗口,而是把XWindow作为Emacs的子控件,然后用 X11 offscreen 技术把不同Window的XWindow画面进行同步,但用的不是粘贴的技术。

而是每个平台用不同的控件作为Emacs的子控件,不同平台要写不同的窗口代码,维护代价比较高。

我看了他的源码实现,估计性能一般,期待以后有人测试一下。

好处是,估计 org-mode 这种文件里面可以 web/text 混合排版,这个没测试过。

1 个赞

Po Lu代码我看了,对底层图形还是比较了解的,这么多补丁令人敬佩。

我其实一直期望Emacs把那些蹩脚的插件从Emacs中去掉,比如 newsticker, gnus, emms 等等,这些插件在多媒体渲染和多线程上都不擅长。

把这些插件移动到Emacs外部后,Emacs核心可以专注在Elisp语言功能、执行效率、图形绘制性能、多线程等核心功能的提升上。

当然,这些都是美好的愿望,Emacs太臃肿,但同时也是它的好处,啥都有。

1 个赞

这个要看包的维护者了,如果包已经没有维护者,那还是留在原地好,因为emacs改接口的时候,最起码会照顾照顾它们,让它们能用,分出去的前提是要有人维护,不然分出去就代表废弃了

4 个赞

唉,这几块,看邮件列表里面往往是长篇大论但没有结论

1 个赞

因为讨论的人都是语言设计和图形编程菜鸟,很少有人像Po Lu这样,别废话直接干。

:rofl: :rofl: :rofl:

https://lists.gnu.org/archive/html/emacs-devel/2021-11/msg01459.html

Po Lu has already answered all your question, and we have already decided to add GStreamer support to Emacs.

RMS 说已经决定要加了

EDIT: 是我看错了,这个邮件并不是 RMS 发的 :joy:

用 Emacs 剪辑视频指日可待?

3 个赞

Master 分支已经支持 emoji 了(C-x 8 e),Emacs 更现代了, :grinning:

2 个赞

要说明一下,X-Windows 下最接近其他窗口系统“子控件”的概念就是 Window。不管是 GTK+,还是 Xt,他们的“widget”都使用 Window 来实现的。不过 GTK+ 2.18 后就开始使用 client side windows,所以不是每个 GdkWindow 都会有 XID,也因此会导致 xwidget 闪烁。

而我用 X 服务器端的 Window 来实现 xwidget 是因为 Emacs 不使用来自于 GTK 的 cr_surface 来绘图,所以重新显示的过程中就会把 xwidget_view 的 GdkWindow 覆盖,导致闪烁现象。

我虽然用了 20 多年 Emacs,今日之前从来没有关注过这个论坛,所以我如果违背了论坛的风俗习惯或潜规则,敬请谅解,谢谢啊(

19 个赞

在我的测试中,依赖 GdkOffscreenWindow 做到画面同步不会对运行速度做到多大的影响(可以随便以 45 FPS 的速度运行装满 6000 条鱼的 webgl aquarium。)不过必须说到,只有 GTK+ xwidget 才需要使用 offscreen rendering,而 GStreamer xwidget 是通过动态改变 GStreamer pipeline 来实现的,可以任意利用硬件加速,不会影响速度或 CPU 效用。

我估计如果使用 WPE 来做 webkit widget 也能达到类似 GStreamer 动态管道的效果,能利用 WPE 的内置分头功能来做到不牺牲性能的分头化显示。

2 个赞

画面同步主要是照顾Emacs的视窗分屏设计,如果不做画面同步浏览器应用就会导致多实例的问题。 画面同步只要在 X11 Server端做,避免 Sever-Client 之间拷贝大量图形数据都不会卡顿。

我在EAF主要用 QGraphicsScene 和 QGraphicsView 来分别实现Emacs中 Buffer 和 View 的概念,Qt这两个库都是基于GPU来实现的,效率很高,而且支持Windows, Mac, Linux、 BSD等多个平台。

GDK的实现问题是只能兼顾Linux平台,不同平台要用不同的图形服务来分别写代码,维护代价要比EAF这种实现大很多,相当于在Emacs中实现跨平台的图形绘制API.

GSteamer我觉得没啥必要,API太复杂了,视频绘制Gtk/Qt默认的控件就足够了,如果视频编辑, 浏览器+JavaScript库就好了。

是啊,xwidget这种目标就是要在Server端实现才会不闪烁不卡顿。

GdkOffscreenWindow 支持任何 GDK 支持的平台,也包括 GNU/Linux 以外的各种 Unix 版本,和 MS Windows(不过这里的代码还依赖于 X-Windows)。而且,只要支持 XRender 和 MIT-SHM,GdkOffscreenWindow 中也能做到硬件加速,基本上不需要担心性能问题。

GStreamer widget 也做到了完整的画面同步,不会出现多实例问题。

我个人认为维护成本不是问题,而 EAF 的方式是无法在 Wayland 上实现的,因为 Wayland 禁止应用任意排放窗口。

2 个赞