Weird blinking, mostly when in focus

[MagicRB]

After commit 7c9f82b64b244f2e9f7630fcdd3d6bc0f85687df, I can successfully see webkit in Emacs, but it sort of randomly blinks. Disappears and reappears, it seems to be tied to focus and mouse movement, as it blinks much more when I move my mouse and also stops when I go into another frame, for example helm. There is no useful debug print info. BTW I'm using pgtk native comp emacs

[yqu212]

I encountered the same issue. But I use emacs master branch.

[MagicRB]

gtk it's not related to pgtk or native-comp. I'm guessing you're on Xorg, and which driver?

[yqu212]

Yes. I use wsl.

[akirakyle]

@MagicRB Is this a regression then? Are you running pgtk on wayland or on x?

[yqu212]

Mine is on x. WebKit shows, but it blinks.

[MagicRB]

I'm on X too, and pgtk nativecomp. I don't know if I'd call it a regression.. since it didn't work at all

[VCTR18]

I'm using emacs 28 on an out of the box kubuntu 20.0.4, and I experience the same issue, using this tool or the native xwidget-webkit browser, compiled with appropiate support.

[akirakyle]

So as I suspected this is related to Emacs' double buffering implementation on X. Running (modify-frame-parameters nil '((inhibit-double-buffering . t))) will disable double buffering for the frame it's executed in and, at least for me, stops the flickering. Of course then emacs starts suffering screen tearing.

See this post about implementing double buffering on X and note that this was implemented in 2016 while xwidgets were mainly implemented in 2012. I suspect xwidgets have flickered ever since then and no one has noticed or bothered to look into it. Interestingly as part of making emacs double buffered, it looks like gtk widgets such as scroll bars were implemented as a separate window and I wonder if that's because they suffer this same flickering if they're part of the double buffered window. I don't really have the motivation to try to fundamentally fix this problem since, as that post points out, the xterm.c code is a bit of a mess and I suspect the fix will have to happen somewhere deep in that mess. So there are two possible work arounds. There's inhibiting double buffering, or theres attempting to go the EAF route and xembed the webkit view which would presumably also fix the flicker.

[MagicRB]

Hmm, another bit of Emacs code everyone is afraid to touch :D, I think that XEmbed is the way to go. I imagine it shouldn't be that hard to do right? btw, how did you even figure this out?

[akirakyle]

I think that XEmbed is the way to go. I imagine it shouldn't be that hard to do right?

Yeah it probably is the way to go, unless people are very fond of that retro screen tearing experience ;) Gtk has the GtkPlug widget which should handle the hard bits so yeah, shouldn't be too difficult.

btw, how did you even figure this out?

I credit emacs with teaching me the best way to understand something is to just start reading the code that implements it. Documentation alone can only be so helpful.

[VCTR18]

So as I suspected this is related to Emacs' double buffering implementation on X. Running (modify-frame-parameters nil '((inhibit-double-buffering . t))) will disable double buffering for the frame it's executed in and, at least for me, stops the flickering. Of course then emacs starts suffering screen tearing.

See this post about implementing double buffering on X and note that this was implemented in 2016 while xwidgets were mainly implemented in 2012. I suspect xwidgets have flickered ever since then and no one has noticed or bothered to look into it. Interestingly as part of making emacs double buffered, it looks like gtk widgets such as scroll bars were implemented as a separate window and I wonder if that's because they suffer this same flickering if they're part of the double buffered window. I don't really have the motivation to try to fundamentally fix this problem since, as that post points out, the xterm.c code is a bit of a mess and I suspect the fix will have to happen somewhere deep in that mess. So there are two possible work arounds. There's inhibiting double buffering, or theres attempting to go the EAF route and xembed the webkit view which would presumably also fix the flicker.

But then, does it work on your setup, or your emacs also flickers with this browser? I dont understand.

[MagicRB]

I credit emacs with teaching me the best way to understand something is to just start reading the code that implements it. Documentation alone can only be so helpful.

That approach starts to be an issue, when you don't understand the code. I still have trouble processing elisp even though I've using Emacs for roughly 5 months and let's not get started on my C skills...

@VCTR18

But then, does it work on your setup, or your emacs also flickers with this browser? I dont understand.

he's on wayland

[inigoserna]

But then, does it work on your setup, or your emacs also flickers with this browser? I dont understand.

Disabling double buffering as @akirakyle said, eliminated flickering on my X builds. It works smoothly indeed. On the other hand, I don't know the inconveniences of it.

[VCTR18]

I credit emacs with teaching me the best way to understand something is to just start reading the code that implements it. Documentation alone can only be so helpful.

That approach starts to be an issue, when you don't understand the code. I still have trouble processing elisp even though I've using Emacs for roughly 5 months and let's not get started on my C skill...

@VCTR18

But then, does it work on your setup, or your emacs also flickers with this browser? I dont understand.

he's on wayland

So?

[VCTR18]

The elisp command has disabled the flickering, thanks. Any idea how to enable youtube videos?

[akirakyle]

On the other hand, I don't know the inconveniences of it.

Screen tearing and white flashes. The post I linked explained some of this. Of course the extent of the visual glitches you'll see are highly dependent on your hardware.

[akirakyle]

@VCTR18 On wayland there is no flickering as I think gtk handles double buffering all the rendering. On X, emacs handles double buffering itself through an X extension, but this interferes with gtk drawing itself to the screen and appears to result in the flickering.

As far as enabling videos, that's going to be dependent on your webkitgtk build having enabled video and having proper GStreamer support. The enable-media setting is true by default so if you don't see videos working I would check with your distro's webkitgtk package if there's an optional gstreamer package that needs to be also installed or something else along those lines.

[akirakyle]

I should also add that there doesn't appear to be flickering when using emacs --with-pgtk on X which makes sense as gtk should still be handling double buffering there as well.

[MagicRB]

ok, thanks, good to know that my pgtk is setup wrong... I thought it was working...

[akirakyle]

@MagicRB The first thing to double check would be that (window-system) returns pgtk to ensure that your emacs frame really is a pgtk frame.

[yqu212]

Webkit now works without flickering. However, webkit disappears temporariily. When I switch from webkit buffer to other buffer or from other buffer to webkit buffer, webkit disappears until I move my mouse. Anyway, Webkit works now. Thanks.

[akirakyle]

@yqu212 I also observe that. I think the xembed work around would fix that so maybe I'll try implementing that when I get the chance.

[yqu212]

OK. I'm looking forward to your workaround.

By the way, If I use emacs pgtk branch, can webkit work on x? I'm on wsl and use emacs gui through a xserver.

[akirakyle]

Yes emacs pgtk should work fine on X with emacs-webkit

[yqu212]

Thanks. I will try it.

[tumashu]

I have tested with the below code:

(modify-frame-parameters nil '((inhibit-double-buffering . t)))
(require 'webkit)

The below is a snapshot:

HwVideoEditor_2020_11_28_131056.mp4.zip

[tumashu]

When click a link and switch to another webkit, it will show emacs buffer, especially when buffer is black color

[yqu212]

I have observed the same behavior. I think we can try pgtk branch now.

[yqu212]

@MagicRB How about your pgtk setup? Does WebKit work on x without blinks now?

[akirakyle]

I started working on xembed-ing the webkit view when using emacs --with-x, but I realized that this would likely break child frames since the xembeded window will be rendered on top of emacs windows. Is fixing the visual glitches worth breaking child frames for? For now I'm thinking of just setting inhibit-double-buffering and warning that the frame will no longer be double buffered while the webkit view is focused. Also I'm feeling unmotivated to implement xembed as it'll force some refactoring in order to support. The long term fix for this is of course to just use emacs --with-pgtk or use webkit-own-window which could certainly be improved.

[tumashu]

how to use child-frame when current is webkit, if just use ivy-posframe like package, a simple hack way is: hide webkit before show child-frame,

by the way, can xembed approach can handle switch to emacs buffer when click link in webkit

[akirakyle]

simple hack way is: hide webkit before show child-frame

Yeah that's probably sufficient, given child frames appearing seem to cause rendering issues already on x.

by the way, can xembed approach can handle switch to emacs buffer when click link in webkit

If you're referring to the video you sent, than xembed would probably fix that rendering bug. In that case I don't think that there's a buffer switch happening, but just that emacs ends up rendering itself over webkit.

[yqu212]

Webkit works fine on emacs-native-comp-pgtk. Thanks.

[VCTR18]

I had to install a lot of libraries (apt-get install libgstreamer1.0-0 gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0-libav gstreamer1.0-doc gstreamer1.0-tools gstreamer1.0-x gstreamer1.0-alsa gstreamer1.0-gl gstreamer1.0-gtk3 gstreamer1.0-qt5 gstreamer1.0-pulseaudio), but it worked, very well. Thanks.

[MagicRB]

I can confirm that webkit works really well on pgtk

[austinweisgrau]

pgtk fixes this issue for me as well, also fixes #24

Would be great if someone could test this with lucid rather than gtk. I will try and find time to build this.