Re: [dev] Culling all the way down
On Tue, 8 Sep 2020 07:42:21 +0200 Tobias Bengfort wrote: > Hi, > > On 07/09/2020 09.13, Alexander Krotov wrote: > > Maybe a better solution is to send XOFF (see > > https://en.wikipedia.org/wiki/Software_flow_control), but I am also > > not sure how other programs react to it. They will probably block > > waiting for the write(2) syscall to return instead of continuing to > > do work in the background. > > Trying this manually had exactly the desired outcome: CPU usage dropped > to 0. Nice! > > On 06/09/2020 09.48, Mattias Andrée wrote: > > You would just be adding unneeded work and complexity for next to no > > gain. > > Even if there is little gain it might still make sense if the solution > is simple. This feels like it could be simple, but I am not sure. > > Concrete steps: > > - dwm sets _NET_WM_STATE_HIDDEN on windows that are currently not displayed > - st sends XON/XOFF when _NET_WM_STATE_HIDDEN is set > > Do you think this would be reasonable or are there potential issues I am > missing? > > tobias > This is what I suggested, exception XOFF is SIGTSTP whereas I suggested SIGSTOP. SIGSTOP will stop the process no matter what, and that's probably what you want, you want it to stop working entirely even if its not actually printing anything at the moment. However, in some cases, such as a visualising audio player or a video player, you would want to suppress output but not stop at output or at all; this would require some other solution like resizing the terminal to (0, 0) or sending a string to the program. Of course, you will have to make this something the program has to opt in for, otherwise it cause be stopped when this is not desired, which is in most cases isn't. Regards, Mattias Andrée
Re: [dev] Culling all the way down
Hi, On 07/09/2020 09.13, Alexander Krotov wrote: > Maybe a better solution is to send XOFF (see > https://en.wikipedia.org/wiki/Software_flow_control), but I am also > not sure how other programs react to it. They will probably block > waiting for the write(2) syscall to return instead of continuing to > do work in the background. Trying this manually had exactly the desired outcome: CPU usage dropped to 0. Nice! On 06/09/2020 09.48, Mattias Andrée wrote: > You would just be adding unneeded work and complexity for next to no > gain. Even if there is little gain it might still make sense if the solution is simple. This feels like it could be simple, but I am not sure. Concrete steps: - dwm sets _NET_WM_STATE_HIDDEN on windows that are currently not displayed - st sends XON/XOFF when _NET_WM_STATE_HIDDEN is set Do you think this would be reasonable or are there potential issues I am missing? tobias
Re: [dev] Culling all the way down
On Mon, 7 Sep 2020 10:13:26 +0300 Alexander Krotov wrote: > > What you could do is to patch a terminal to allow programs to because > > paused via SIGSTOP when invisible and continued via SIGCONT when > > visible. Then your program would only need to write some string to > > the terminal when it starts and when it terminates. Multiplexers > > could however become an issue, but you could patch one as well. > > Sending SIGSTOP stops even the programs that simply do something in the > background, like software update. This will make it impossible to run > something like "apt-get upgrade" in invisible terminal. I meant that this would be something the application would explicitly have to opt in for by writing a special string to the terminal. > > Maybe a better solution is to send XOFF (see > https://en.wikipedia.org/wiki/Software_flow_control), but I am also not > sure how other programs react to it. They will probably block waiting > for the write(2) syscall to return instead of continuing to do work in > the background. > > If they use separate threads/coroutines for the work and for progress > bar update, they will continue to work while progress bar will be > blocked. Once unlocked, they will send the rest of previous progress bar > update, skip all the "frames" that were never displayed and display the > final state. > > Looks like doing an XOFF patch for st and fixing all the programs that > can't handle it properly is the "right thing", but prepare to discover > that badly written programs will stop or even timeout with an error. >
Re: [dev] Culling all the way down
> What you could do is to patch a terminal to allow programs to because > paused via SIGSTOP when invisible and continued via SIGCONT when > visible. Then your program would only need to write some string to > the terminal when it starts and when it terminates. Multiplexers > could however become an issue, but you could patch one as well. Sending SIGSTOP stops even the programs that simply do something in the background, like software update. This will make it impossible to run something like "apt-get upgrade" in invisible terminal. Maybe a better solution is to send XOFF (see https://en.wikipedia.org/wiki/Software_flow_control), but I am also not sure how other programs react to it. They will probably block waiting for the write(2) syscall to return instead of continuing to do work in the background. If they use separate threads/coroutines for the work and for progress bar update, they will continue to work while progress bar will be blocked. Once unlocked, they will send the rest of previous progress bar update, skip all the "frames" that were never displayed and display the final state. Looks like doing an XOFF patch for st and fixing all the programs that can't handle it properly is the "right thing", but prepare to discover that badly written programs will stop or even timeout with an error.
Re: [dev] Culling all the way down
On Sun, 6 Sep 2020 09:48:06 +0200 Mattias Andrée wrote: > On Sun, 6 Sep 2020 08:21:45 +0200 > Tobias Bengfort wrote: > > > Hi, > > > > I am currently creating a curses application that is updated > > independently of user input. Think of something like `top`. I realized > > that the process is using the same amount of CPU whether it is currently > > visible or not. That bothers me. I would prefer if my app got notified > > when its visibility changes so it can stop rendering (I think this is > > called culling). > > > > For this to work it would need to be supported in several places: > > > > - Window managers could set _NET_WM_STATE_HIDDEN > > - Terminal emulators and multiplexers could set the terminal size to 0,0 > > - Applications need to actually use that information > > > > The only project I could find that seems to do something like this is > > mutter. > > > > So I am wondering: Is this even worth the effort? Have I missed any > > prior art? > > > > thanks > > tobias > > > > Hi! > > htop, with a refresh rate of 1, uses of 1% of one the (3.40GHz) CPUs, > I don't think this is a problem as people don't generally max out the > CPUs. And I wouldn't think people have it running without being able > to see it either. You would just be adding unneeded work and complexity > for next to no gain. I would only think about this for intensive programs. > > > Regards, > Mattias Andrée Hi again! What you could do is to patch a terminal to allow programs to because paused via SIGSTOP when invisible and continued via SIGCONT when visible. Then your program would only need to write some string to the terminal when it starts and when it terminates. Multiplexers could however become an issue, but you could patch one as well. Regards, Mattias Andrée
Re: [dev] Culling all the way down
On Sun, 6 Sep 2020 08:21:45 +0200 Tobias Bengfort wrote: > Hi, > > I am currently creating a curses application that is updated > independently of user input. Think of something like `top`. I realized > that the process is using the same amount of CPU whether it is currently > visible or not. That bothers me. I would prefer if my app got notified > when its visibility changes so it can stop rendering (I think this is > called culling). > > For this to work it would need to be supported in several places: > > - Window managers could set _NET_WM_STATE_HIDDEN > - Terminal emulators and multiplexers could set the terminal size to 0,0 > - Applications need to actually use that information > > The only project I could find that seems to do something like this is > mutter. > > So I am wondering: Is this even worth the effort? Have I missed any > prior art? > > thanks > tobias > Hi! htop, with a refresh rate of 1, uses of 1% of one the (3.40GHz) CPUs, I don't think this is a problem as people don't generally max out the CPUs. And I wouldn't think people have it running without being able to see it either. You would just be adding unneeded work and complexity for next to no gain. I would only think about this for intensive programs. Regards, Mattias Andrée
[dev] Culling all the way down
Hi, I am currently creating a curses application that is updated independently of user input. Think of something like `top`. I realized that the process is using the same amount of CPU whether it is currently visible or not. That bothers me. I would prefer if my app got notified when its visibility changes so it can stop rendering (I think this is called culling). For this to work it would need to be supported in several places: - Window managers could set _NET_WM_STATE_HIDDEN - Terminal emulators and multiplexers could set the terminal size to 0,0 - Applications need to actually use that information The only project I could find that seems to do something like this is mutter. So I am wondering: Is this even worth the effort? Have I missed any prior art? thanks tobias
