Flashing with vis #141

Closed
opened 1 year ago by JorwLNKwpH · 11 comments

Whenever I close vis, the screen visibly flashes blue at the bottom. I wonder if this can be fixed or mitigated on foot's side?

Whenever I close [vis](https://github.com/martanne/vis), the screen visibly flashes blue at the bottom. I wonder if this can be fixed or mitigated on foot's side?
dnkl commented 1 year ago
Owner

I'm having trouble reproducing this. Any chance you can capture this in a video? Can you post the log output from foot?

I'm having trouble reproducing this. Any chance you can capture this in a video? Can you post the log output from foot?
dnkl commented 1 year ago
Owner

Might be related to the color scheme(s). What does your foot color scheme look like, and what scheme do you use in vis (posting the configuration snippets here will hopefully allow me to reproduce the issue).

Might be related to the color scheme(s). What does your foot color scheme look like, and what scheme do you use in vis (posting the configuration snippets here will hopefully allow me to reproduce the issue).
Poster

I think you are right that this is color scheme related (or at least the bug is only visible on certain color schemes). I tested a light foot color scheme and did not notice anything. However, testing gruvbox foot with gruvbox vis results in green flashing when you close vis.

foot color scheme:

background=282828                                                               
foreground=d5c4a1                                                               
regular0=282828                                                                 
regular1=fb4934                                                                 
regular2=b8bb26                                                                 
regular3=fabd2f                                                                 
regular4=83a598                                                                 
regular5=d3869b                                                                 
regular6=8ec07c                                                                 
regular7=d5c4a1                                                                 
bright0=665c54                                                                  
bright1=fb4934                                                                  
bright2=b8bb26                                                                  
bright3=fabd2f                                                                  
bright4=83a598                                                                  
bright5=d3869b                                                                  
bright6=8ec07c                                                                  
bright7=d5c4a1    

vis color scheme:
https://raw.githubusercontent.com/pshevtsov/base16-vis/master/themes/base16-gruvbox-dark-medium.lua

I think you are right that this is color scheme related (or at least the bug is only visible on certain color schemes). I tested a light foot color scheme and did not notice anything. However, testing gruvbox foot with gruvbox vis results in green flashing when you close vis. foot color scheme: ``` background=282828 foreground=d5c4a1 regular0=282828 regular1=fb4934 regular2=b8bb26 regular3=fabd2f regular4=83a598 regular5=d3869b regular6=8ec07c regular7=d5c4a1 bright0=665c54 bright1=fb4934 bright2=b8bb26 bright3=fabd2f bright4=83a598 bright5=d3869b bright6=8ec07c bright7=d5c4a1 ``` vis color scheme: https://raw.githubusercontent.com/pshevtsov/base16-vis/master/themes/base16-gruvbox-dark-medium.lua
dnkl commented 1 year ago
Owner

Thanks! Unfortunately, I'm still unable to reproduce. This tells me it might be timing related.

  • What kind of hardware are you running?
  • Does the flash happen every time? Or only now and then?
  • Is foot the only terminal emulator you're seeing this on?
  • Have you changed any foot options from their defaults (besides the colors)?
Thanks! Unfortunately, I'm still unable to reproduce. This tells me it might be timing related. * What kind of hardware are you running? * Does the flash happen **every** time? Or only now and then? * Is foot the _only_ terminal emulator you're seeing this on? * Have you changed _any_ foot options from their defaults (besides the colors)?
Poster
  • What kind of hardware are you running?

Dual core x86_64 laptop (foot uses 2 rendering threads since I turned SMT off).
60 Hz 1920x1080 13.3" display without scaling on sway

  • Does the flash happen every time? Or only now and then?

It doesn't happen every time but most of the time.

  • Is foot the only terminal emulator you're seeing this on?

Yes, the flashing only happens on foot.

However on qterminal, the screen is blue and vis is not useable. This is because qterminal does not support OSC4. I think qterminal is basically an older version of konsole, so that bug will happen with konsole unless konsole added support for OSC4 recently.
https://github.com/martanne/vis/wiki/FAQ#my-terminal-colors-are-messed-up-what-is-going-on

  • Have you changed any foot options from their defaults (besides the colors)?

I've made a few changes, but most of the changes are cosmetic.

font=Source Code Pro:size=6, Twemoji:size=5.2055                                
initial-window-size-chars=80x25                                                 
[cursor]                                                                        
style=bar
[scrollback]                                                                    
lines=4096                                                                      
[tweak]                                                                         
allow-overflowing-double-width-glyphs=true     

Also I added a recording. The flash's color and area can be different though with different color schemes (and hardware?).

> * What kind of hardware are you running? Dual core x86_64 laptop (foot uses 2 rendering threads since I turned SMT off). 60 Hz 1920x1080 13.3" display without scaling on sway > * Does the flash happen **every** time? Or only now and then? It doesn't happen every time but most of the time. > * Is foot the _only_ terminal emulator you're seeing this on? Yes, the flashing only happens on foot. However on qterminal, the screen is blue and vis is not useable. This is because qterminal does not support OSC4. I think qterminal is basically an older version of konsole, so that bug will happen with konsole unless konsole added support for OSC4 recently. https://github.com/martanne/vis/wiki/FAQ#my-terminal-colors-are-messed-up-what-is-going-on > * Have you changed _any_ foot options from their defaults (besides the colors)? I've made a few changes, but most of the changes are cosmetic. ``` font=Source Code Pro:size=6, Twemoji:size=5.2055 initial-window-size-chars=80x25 [cursor] style=bar [scrollback] lines=4096 [tweak] allow-overflowing-double-width-glyphs=true ``` Also I added a recording. The flash's color and area can be different though with different color schemes (and hardware?).
dnkl commented 1 year ago
Owner

Thanks!

This is a bit of a long shot, but that recording looks like foot's flash escape sequence is triggered. This sequence is defined in the terminfo, and is named flash. I have no idea why that sequence would be triggered here, and I could be wrong.

But it's easy to disable it, so lets try this first. Can you apply this patch and test again?

diff --git a/osc.c b/osc.c
index 7e22d7c..a943f71 100644
--- a/osc.c
+++ b/osc.c
@@ -252,8 +252,10 @@ osc_selection(struct terminal *term, char *string)
 static void
 osc_flash(struct terminal *term)
 {
+#if 0
     /* Our own private - flash */
     term_flash(term, 50);
+#endif
 }
 
 static bool

If this isn't it, it's probably related to vis restoring the default color palette on exit.

Thanks! This is a bit of a long shot, but that recording looks like foot's `flash` escape sequence is triggered. This sequence is defined in the terminfo, and is named `flash`. I have no idea why that sequence would be triggered here, and I could be wrong. But it's easy to disable it, so lets try this first. Can you apply this patch and test again? ```diff diff --git a/osc.c b/osc.c index 7e22d7c..a943f71 100644 --- a/osc.c +++ b/osc.c @@ -252,8 +252,10 @@ osc_selection(struct terminal *term, char *string) static void osc_flash(struct terminal *term) { +#if 0 /* Our own private - flash */ term_flash(term, 50); +#endif } static bool ``` If this isn't it, it's probably related to vis restoring the default color palette on exit.
Poster

Thanks for the patch!

However, it doesn't seem like it changed anything.

Thanks for the patch! However, it doesn't seem like it changed anything.
dnkl commented 1 year ago
Owner

However, it doesn’t seem like it changed anything.

Almost expected... at least we've eliminated that possibility.

So, I have a couple of more questions:

  • Can you reproduce the flash with the default/empty configuration in vis?
  • Which shell are you running?

Looking at a trace of the escapes vis sends, it appears it doesn't change the default foreground/background color, but only the color palette.

At exit, it resets the color palette without clearing the screen first, and before exiting the alternate screen. Since vis doesn't change the foreground/background color, I assume it paints the background explicitly, using one of the colors from the palette (this becomes obvious when you enter a command in vis; the background used here appears to be the default background).

This means there will be this kind of flash since vis emits the reset sequence while the entire background is painted with a color it now is changing.

Normally(?) you wouldn't notice this, if vis quits "fast" enough. In this case, foot will never get the chance to render the vis background (with the just-changed color).

At least that's my theory.

There are two things we could try now.

One is removing the "render refresh" call when the color palette is reset. This could mean you get color artifacts when you exit vis (until the screen is refreshed by other means - a window resize for example). But if it gets rid of the flash, it means it is a timing issue.

The other thing we can do is get a trace of the escape sequences you see when you exit vis. This could in theory tell us whether vis is doing something more in your case. Either taking too long to quit, or sending other escapes that I'm not seeing.

Here's a patch for the first point:

diff --git a/osc.c b/osc.c
index 7e22d7c..a7b8fcf 100644
--- a/osc.c
+++ b/osc.c
@@ -705,7 +705,7 @@ osc_dispatch(struct terminal *term)
             }
         }
 
-        render_refresh(term);
+        // render_refresh(term);
         break;
     }
 

And here's a patch for the second point. You'll need to run foot from another terminal, to see the log output. It will log quite a bit, so I'd suggest you "prepare" vis for quitting (i.e. hit : q, but don't press enter, then switch to the first terminal and hit enter a couple of times to get some space between the "old" log output, and the log output that will come once you quit vis. Then switch back and actually quit vis.

diff --git a/csi.c b/csi.c
index 53a9080..e22983e 100644
--- a/csi.c
+++ b/csi.c
@@ -13,7 +13,7 @@
 #include <sys/timerfd.h>
 
 #define LOG_MODULE "csi"
-#define LOG_ENABLE_DBG 0
+#define LOG_ENABLE_DBG 1
 #include "log.h"
 #include "grid.h"
 #include "selection.h"
diff --git a/osc.c b/osc.c
index 7e22d7c..3c0306a 100644
--- a/osc.c
+++ b/osc.c
@@ -7,7 +7,7 @@
 #include <unistd.h>
 
 #define LOG_MODULE "osc"
-#define LOG_ENABLE_DBG 0
+#define LOG_ENABLE_DBG 1
 #include "log.h"
 #include "base64.h"
 #include "grid.h"
diff --git a/vt.c b/vt.c
index 6b6bbd0..de89286 100644
--- a/vt.c
+++ b/vt.c
@@ -6,7 +6,7 @@
 #include <assert.h>
 
 #define LOG_MODULE "vt"
-#define LOG_ENABLE_DBG 0
+#define LOG_ENABLE_DBG 1
 #include "log.h"
 #include "csi.h"
 #include "dcs.h"

Note that you need to do this in a debug build, or you wont get any output at all. Please don't run this patch together with the first patch. Make sure you post the trace from a run where you saw a flash.

> However, it doesn’t seem like it changed anything. Almost expected... at least we've eliminated that possibility. So, I have a couple of more questions: * Can you reproduce the flash with the default/empty configuration in vis? * Which shell are you running? Looking at a trace of the escapes vis sends, it appears it doesn't change the default foreground/background color, but only the color palette. At exit, it resets the color palette **without** clearing the screen first, and **before** exiting the alternate screen. Since vis doesn't change the foreground/background color, I assume it paints the background explicitly, using one of the colors from the palette (this becomes obvious when you enter a command in vis; the background used here appears to be the default background). This means there **will** be this kind of flash since vis emits the reset sequence while the entire background is painted with a color it now is changing. Normally(?) you wouldn't notice this, if vis quits "fast" enough. In this case, foot will never get the chance to render the vis background (with the just-changed color). At least that's my theory. There are two things we could try now. One is removing the "render refresh" call when the color palette is reset. This could mean you get color artifacts when you exit vis (until the screen is refreshed by other means - a window resize for example). But if it gets rid of the flash, it means it is a timing issue. The other thing we can do is get a trace of the escape sequences you see when you exit vis. This could in theory tell us whether vis is doing something more in your case. Either taking too long to quit, or sending other escapes that I'm not seeing. Here's a patch for the first point: ```diff diff --git a/osc.c b/osc.c index 7e22d7c..a7b8fcf 100644 --- a/osc.c +++ b/osc.c @@ -705,7 +705,7 @@ osc_dispatch(struct terminal *term) } } - render_refresh(term); + // render_refresh(term); break; } ``` And here's a patch for the second point. You'll need to run foot from another terminal, to see the log output. It will log quite a bit, so I'd suggest you "prepare" vis for quitting (i.e. hit `: q`, but don't press enter, then switch to the first terminal and hit enter a couple of times to get some space between the "old" log output, and the log output that will come once you quit vis. Then switch back and actually quit vis. ```diff diff --git a/csi.c b/csi.c index 53a9080..e22983e 100644 --- a/csi.c +++ b/csi.c @@ -13,7 +13,7 @@ #include <sys/timerfd.h> #define LOG_MODULE "csi" -#define LOG_ENABLE_DBG 0 +#define LOG_ENABLE_DBG 1 #include "log.h" #include "grid.h" #include "selection.h" diff --git a/osc.c b/osc.c index 7e22d7c..3c0306a 100644 --- a/osc.c +++ b/osc.c @@ -7,7 +7,7 @@ #include <unistd.h> #define LOG_MODULE "osc" -#define LOG_ENABLE_DBG 0 +#define LOG_ENABLE_DBG 1 #include "log.h" #include "base64.h" #include "grid.h" diff --git a/vt.c b/vt.c index 6b6bbd0..de89286 100644 --- a/vt.c +++ b/vt.c @@ -6,7 +6,7 @@ #include <assert.h> #define LOG_MODULE "vt" -#define LOG_ENABLE_DBG 0 +#define LOG_ENABLE_DBG 1 #include "log.h" #include "csi.h" #include "dcs.h" ``` Note that you need to do this in a debug build, or you wont get any output at all. Please don't run this patch together with the first patch. Make sure you post the trace from a run where you saw a flash.
Poster

Thanks for the explanation!

Can you reproduce the flash with the default/empty configuration in vis?

Yes and I uploaded a video with it, too. You can see the blue flash at the bottom.

Which shell are you running?

I've tested bash, dash, OpenBSD ksh, and fish, so I don't think it's related to the shell.

The first patch, commenting out render_refresh(), seems to get rid of the flashing.

Here's the output from the second patch:

 dbg: osc.c:531: OCS: 104; (param = 104)
 dbg: osc.c:681: resetting all colors
 dbg: csi.c:632: CSI: 39;49m (2 parameters)
 dbg: osc.c:531: OCS: 104 (param = 104)
 dbg: osc.c:681: resetting all colors
 dbg: vt.c:347: ESC: \E\
 dbg: csi.c:632: CSI: 61;1H (2 parameters)
 dbg: vt.c:335: collect: ?
 dbg: csi.c:632: CSI: 12?l (1 parameters)
 dbg: vt.c:335: collect: ?
 dbg: csi.c:632: CSI: 25?h (1 parameters)
 dbg: vt.c:335: collect: ?
 dbg: csi.c:632: CSI: 1049?l (1 parameters)
 dbg: csi.c:632: CSI: 23;0;0t (3 parameters)
 dbg: vt.c:115: execute: 0x0d
 dbg: vt.c:335: collect: ?
 dbg: csi.c:632: CSI: 1?l (1 parameters)
 dbg: vt.c:347: ESC: \E>
 dbg: vt.c:335: collect: ?
 dbg: csi.c:632: CSI: 1?l (1 parameters)
 dbg: vt.c:347: ESC: \E>
 dbg: csi.c:632: CSI: 119C (1 parameters)
 dbg: csi.c:632: CSI: 26D (1 parameters)
 dbg: csi.c:632: CSI: 34m (1 parameters)
 dbg: vt.c:335: collect: (
 dbg: vt.c:347: ESC: \E(B
 dbg: csi.c:632: CSI: m (0 parameters)
 dbg: vt.c:115: execute: 0x0d
 dbg: vt.c:115: execute: 0x0a
 dbg: csi.c:632: CSI: 2m (1 parameters)
 dbg: vt.c:335: collect: (
 dbg: vt.c:347: ESC: \E(B
 dbg: csi.c:632: CSI: m (0 parameters)
 dbg: vt.c:115: execute: 0x0d
 dbg: vt.c:115: execute: 0x0d
 dbg: csi.c:632: CSI: K (0 parameters)
 dbg: vt.c:335: collect: ?
 dbg: csi.c:632: CSI: 2004?h (1 parameters)
 dbg: osc.c:531: OCS: 0;fish /home/travankor (param = 0)
 dbg: csi.c:632: CSI: 30m (1 parameters)
 dbg: vt.c:335: collect: (
 dbg: vt.c:347: ESC: \E(B
 dbg: csi.c:632: CSI: m (0 parameters)
 dbg: csi.c:632: CSI: 32m (1 parameters)
 dbg: csi.c:632: CSI: 1m (1 parameters)
 dbg: csi.c:632: CSI: 32m (1 parameters)
 dbg: csi.c:632: CSI: 1m (1 parameters)
 dbg: csi.c:632: CSI: 33m (1 parameters)
 dbg: csi.c:632: CSI: 1m (1 parameters)
 dbg: csi.c:632: CSI: 37m (1 parameters)
 dbg: csi.c:632: CSI: 1m (1 parameters)
 dbg: csi.c:632: CSI: 34m (1 parameters)
 dbg: csi.c:632: CSI: 1m (1 parameters)
 dbg: csi.c:632: CSI: 37m (1 parameters)
 dbg: csi.c:632: CSI: 1m (1 parameters)
 dbg: csi.c:632: CSI: 32m (1 parameters)
 dbg: vt.c:335: collect: (
 dbg: vt.c:347: ESC: \E(B
 dbg: csi.c:632: CSI: m (0 parameters)
 dbg: csi.c:632: CSI: 32m (1 parameters)
 dbg: csi.c:632: CSI: 1m (1 parameters)
 dbg: csi.c:632: CSI: 32m (1 parameters)
 dbg: vt.c:335: collect: (
 dbg: vt.c:347: ESC: \E(B
 dbg: csi.c:632: CSI: m (0 parameters)
 dbg: csi.c:632: CSI: 32m (1 parameters)
 dbg: csi.c:632: CSI: 1m (1 parameters)
 dbg: csi.c:632: CSI: 32m (1 parameters)
 dbg: vt.c:115: execute: 0x0d
 dbg: vt.c:115: execute: 0x0a
 dbg: vt.c:335: collect: (
 dbg: vt.c:347: ESC: \E(B
 dbg: csi.c:632: CSI: m (0 parameters)
 dbg: vt.c:335: collect: (
 dbg: vt.c:347: ESC: \E(B
 dbg: csi.c:632: CSI: m (0 parameters)
 dbg: csi.c:632: CSI: 32m (1 parameters)
 dbg: csi.c:632: CSI: 1m (1 parameters)
 dbg: csi.c:632: CSI: 31m (1 parameters)
 dbg: vt.c:335: collect: (
 dbg: vt.c:347: ESC: \E(B
 dbg: csi.c:632: CSI: m (0 parameters)
 dbg: csi.c:632: CSI: 38;2;235;219;178m (5 parameters)
 dbg: csi.c:632: CSI: K (0 parameters)

Thanks for the explanation! >Can you reproduce the flash with the default/empty configuration in vis? Yes and I uploaded a video with it, too. You can see the blue flash at the bottom. >Which shell are you running? I've tested bash, dash, OpenBSD ksh, and fish, so I don't think it's related to the shell. The first patch, commenting out render_refresh(), seems to get rid of the flashing. Here's the output from the second patch: <details> ``` dbg: osc.c:531: OCS: 104; (param = 104) dbg: osc.c:681: resetting all colors dbg: csi.c:632: CSI: 39;49m (2 parameters) dbg: osc.c:531: OCS: 104 (param = 104) dbg: osc.c:681: resetting all colors dbg: vt.c:347: ESC: \E\ dbg: csi.c:632: CSI: 61;1H (2 parameters) dbg: vt.c:335: collect: ? dbg: csi.c:632: CSI: 12?l (1 parameters) dbg: vt.c:335: collect: ? dbg: csi.c:632: CSI: 25?h (1 parameters) dbg: vt.c:335: collect: ? dbg: csi.c:632: CSI: 1049?l (1 parameters) dbg: csi.c:632: CSI: 23;0;0t (3 parameters) dbg: vt.c:115: execute: 0x0d dbg: vt.c:335: collect: ? dbg: csi.c:632: CSI: 1?l (1 parameters) dbg: vt.c:347: ESC: \E> dbg: vt.c:335: collect: ? dbg: csi.c:632: CSI: 1?l (1 parameters) dbg: vt.c:347: ESC: \E> dbg: csi.c:632: CSI: 119C (1 parameters) dbg: csi.c:632: CSI: 26D (1 parameters) dbg: csi.c:632: CSI: 34m (1 parameters) dbg: vt.c:335: collect: ( dbg: vt.c:347: ESC: \E(B dbg: csi.c:632: CSI: m (0 parameters) dbg: vt.c:115: execute: 0x0d dbg: vt.c:115: execute: 0x0a dbg: csi.c:632: CSI: 2m (1 parameters) dbg: vt.c:335: collect: ( dbg: vt.c:347: ESC: \E(B dbg: csi.c:632: CSI: m (0 parameters) dbg: vt.c:115: execute: 0x0d dbg: vt.c:115: execute: 0x0d dbg: csi.c:632: CSI: K (0 parameters) dbg: vt.c:335: collect: ? dbg: csi.c:632: CSI: 2004?h (1 parameters) dbg: osc.c:531: OCS: 0;fish /home/travankor (param = 0) dbg: csi.c:632: CSI: 30m (1 parameters) dbg: vt.c:335: collect: ( dbg: vt.c:347: ESC: \E(B dbg: csi.c:632: CSI: m (0 parameters) dbg: csi.c:632: CSI: 32m (1 parameters) dbg: csi.c:632: CSI: 1m (1 parameters) dbg: csi.c:632: CSI: 32m (1 parameters) dbg: csi.c:632: CSI: 1m (1 parameters) dbg: csi.c:632: CSI: 33m (1 parameters) dbg: csi.c:632: CSI: 1m (1 parameters) dbg: csi.c:632: CSI: 37m (1 parameters) dbg: csi.c:632: CSI: 1m (1 parameters) dbg: csi.c:632: CSI: 34m (1 parameters) dbg: csi.c:632: CSI: 1m (1 parameters) dbg: csi.c:632: CSI: 37m (1 parameters) dbg: csi.c:632: CSI: 1m (1 parameters) dbg: csi.c:632: CSI: 32m (1 parameters) dbg: vt.c:335: collect: ( dbg: vt.c:347: ESC: \E(B dbg: csi.c:632: CSI: m (0 parameters) dbg: csi.c:632: CSI: 32m (1 parameters) dbg: csi.c:632: CSI: 1m (1 parameters) dbg: csi.c:632: CSI: 32m (1 parameters) dbg: vt.c:335: collect: ( dbg: vt.c:347: ESC: \E(B dbg: csi.c:632: CSI: m (0 parameters) dbg: csi.c:632: CSI: 32m (1 parameters) dbg: csi.c:632: CSI: 1m (1 parameters) dbg: csi.c:632: CSI: 32m (1 parameters) dbg: vt.c:115: execute: 0x0d dbg: vt.c:115: execute: 0x0a dbg: vt.c:335: collect: ( dbg: vt.c:347: ESC: \E(B dbg: csi.c:632: CSI: m (0 parameters) dbg: vt.c:335: collect: ( dbg: vt.c:347: ESC: \E(B dbg: csi.c:632: CSI: m (0 parameters) dbg: csi.c:632: CSI: 32m (1 parameters) dbg: csi.c:632: CSI: 1m (1 parameters) dbg: csi.c:632: CSI: 31m (1 parameters) dbg: vt.c:335: collect: ( dbg: vt.c:347: ESC: \E(B dbg: csi.c:632: CSI: m (0 parameters) dbg: csi.c:632: CSI: 38;2;235;219;178m (5 parameters) dbg: csi.c:632: CSI: K (0 parameters) ``` </details>
dnkl commented 1 year ago
Owner

Here’s the output from the second patch:

Nothing special that pops out; looks very similar to what I saw here.

The first patch, commenting out render_refresh(), seems to get rid of the flashing.

Ok, that means I was right; the flash is caused by vis resetting the color palette. Whether or not you'll see a flash depends on two things mainly:

One, the default color palette vs. vis' color palette, and whether or not there's an area on the screen where the two palettes are (vastly) different.

And two, timing. When the palette is reset, foot will update the currently visible cells internally, and schedule a screen refresh. I.e. the refresh doesn't happen immediately.

And as I'm writing this, I realized this: normally, foot adds a small delay before refreshing the screen. This is to avoid flicker when the application does non-atomic screen updates (see delayed-render-* in foot.ini(5)).

But the handler for the OSC color palette schedules an update "as soon as possible". This typically means "after all data we received in the last read(3) has been processed". If that doesn't include the escapes to switch off the alternate screen, you'll see a flash.

I.e. there's a much higher chance of flicker (or flashes, in this case) than normally, as we're bypassing the normal refresh scheduling.

So, I think that that first patch I sent you is actually the correct solution to the entire problem.

I'll need to let this sink in a bit, and do some testing, but I think we're on to something here.

> Here’s the output from the second patch: Nothing special that pops out; looks very similar to what I saw here. > The first patch, commenting out render_refresh(), seems to get rid of the flashing. Ok, that means I was right; the flash **is** caused by vis resetting the color palette. Whether or not you'll see a flash depends on two things mainly: One, the default color palette vs. vis' color palette, and whether or not there's an area on the screen where the two palettes are (vastly) different. And two, timing. When the palette is reset, foot will update the currently visible cells **internally**, and **schedule** a screen refresh. I.e. the refresh doesn't happen immediately. And as I'm writing this, I realized this: normally, foot adds a small delay before refreshing the screen. This is to avoid flicker when the application does non-atomic screen updates (see `delayed-render-*` in `foot.ini(5)`). But the handler for the OSC color palette schedules an update "as soon as possible". This typically means "after all data we received in the last `read(3)` has been processed". If that doesn't include the escapes to switch off the alternate screen, you'll see a flash. I.e. there's a **much** higher chance of flicker (or flashes, in this case) than normally, as we're bypassing the normal refresh scheduling. So, I think that that first patch I sent you is actually the correct solution to the entire problem. I'll need to let this sink in a bit, and do some testing, but I think we're on to something here.
dnkl commented 1 year ago
Owner

@JorwLNKwpH can you test #148? It should fix the flashes...

@JorwLNKwpH can you test https://codeberg.org/dnkl/foot/pulls/148? It _should_ fix the flashes...
dnkl added the
bug
label 1 year ago
dnkl closed this issue 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.