Re: SVG widget in GNU Emacs

[Akira Kyle]

On Wed, Oct 27, 2021 at 6:25 AM Po Lu <luangruo@yahoo.com> wrote:
>
> I don't agree with the statement that they're a dead end, as offscreen
> rendering is not deprecated in GTK 3, which will be with us for the
> foreseeable future.  The changes introduced with GTK 4 are not relevant
> for GTK 3 (and are of a more fundamental nature that put not just
> offscreen rendering, but even the use of Cairo in danger).
>
> Fundamentally, NS xwidgets work the same way as GTK xwidgets, by
> displaying in an offscreen window, and then copying the contents of said
> offscreen window to widgets that are created for each displayed xwidget.

This is not true. Off-screen rendering of webkit views in NS does not
work. See the comment at the top of nsxwidgets. The NS xwidgets
implementation functions in the same (albeit slightly less elegant
way) as emacs-webkit. Namely it enforces a one to one correspondence
between the webview's buffer and it's window. When trying to display
the webview's buffer in two windows, NS xwidgets will message "You
can't share an xwidget (webkit2) among windows." and one window's
contents will be blank. emacs-webkit handles this by always moving the
webview to the focused window and changing the other window to the
next buffer.

> That NS xwidgets (based on the same principles as GTK xwidgets), in
> Akira's words, work better, shows there are no fundamental barriers
> between briding GTK's rendering model and Emacs's display model.

I don't think it's fair to say that just because something works
between emacs and NS, that it will work between emacs and gtk. While
their paradigms are similar, we cannot know how similar or dissimilar
their implementations are given that we cannot inspect the source code
of NS. Furthermore emacs does things differently in the impure X and
gtk display code then it does in the pure gtk display code and the NS
display code it was based on, especially as it concerns the display
event loop.