Re: SVG widget in GNU Emacs

[Po Lu <luangruo@yahoo.com>]

Akira Kyle <ak@akirakyle.com> writes:

> IMHO the current xwidget implementation in emacs should deprecated.

Even though it's not very polished at present, I've seen a great deal of
code rely on the existing xwidgets support.  I think it would be best to
not make it obsolete.

> Po, if you're seriously considering cleaning up this code, it might be
> wise to take a step back and consider what features its trying to
> provide and how. There's a fundamental tension between the
> buffer/window model of emacs and the way gtk implements a MVC paradigm
> that makes it nontrivial for them to be compatible. This situation has
> only worsened as gtk has been moving its api's to better support a
> future with heavy reliance on gpu rendering. IIRC this means the
> offscreen rendering technique employed by xwidgets is being deprecated
> in gtk. Furthermore xwidgets was implemented before webkit was
> transitioned to a containerized worker process architecture so there's
> bugs one has to work through as gtk attempts to take back control of
> things like signal masks that emacs controls when it initializes gtk.
> My impression has actually been that the nsxwidgets have worked far
> better and reliably since that was merged (in fact I remember coming
> across some emacs package out there that relied on xwidgets, but that
> only supported it on macOS as something or another was broken with
> xwidgets on gtk). I suspect the transition from x11 to wayland has
> introduced a lot of bugs and difficulties for really complex gtk
> widgets like webkitgtk.

I understand what the problem in this area is.  But I'd rather have the
existing and (mostly) working xwidgets feature fixed than to waste time
implementing a new one.

> Ultimately I'd rather see effort go into getting pure gtk merged and
> working to eliminate the mess of inpure mixtures of gtk and x11 code
> from emacs (there could of course still be a "pure" X backend for
> those who desire to run emacs with motif). I think as time goes on, it
> will look worse and worse for emacs to need xwayland to run, as
> distributions will stop including it by default.

The pure GTK port will do nothing to resolve the issues here.  I worked
with that port a while ago, eventually porting it to GTK 4, but quickly
lost interest not soon after that.

In fact, I don't even see the problem with running Emacs in Xwayland.
I've been doing that for years ever since Fedora switched to using
Wayland by default, and I've never had any non-minor problems.

All and all, the PGTK port still keeps the existing X11+Cairo display
architecture.  On the GTK3 version of that port, xwidgets still work
like they do on X and NS.  They will not work on GTK 4 anyway, as the
GTK developers have deleted the ability to draw off-screen.

> Also I think there's a lot of work to be done on xdisp.c. As I've seen
> here and elsewhere, there seems to be sustained interest in richer,
> flexible display options to support things like multicolumns or
> buffers in buffers without resorting to clever hacks that work around
> around the limitations of the current linear character arrays that
> emacs represents buffer data as. Browsers with the DOM have obviously
> already solved this problem in a very general way, and it's quite
> popular these days to leave such complexity and optimization effort to
> the browser engine devs and use something like electron. I doubt the
> emacs devs or maintainers would ever consent to running emacs on top
> of chromium or webkit (although there's already the effort to have
> emacs run on servo here https://github.com/emacs-ng/emacs-ng but that

It uses WebRender as a window system for Emacs, not Servo.