Suggestion to solve 'first run' latency
Hi,
I was wondering about the 'first run' being slow as you mention in the README.
What I see in my case is that : it's slow at first call, then it's damn fast ... but only for a few seconds. I mean : if I keep moving window around : it stays fast. If I do nothing for, say, 10 seconds, then I call it again : slow again. I thought it could be related to python being interpreted, so I compiled it and called the .pyc ... exact same behaviour.
After some experiment, it would appeat that it's the call to xrandr that causes the issue : indeed I can see the exact same behaviour when I loop-call xrandr command.
Then, I came accross another nifty utility called 'srandrd', you can find it on github. It does listen to xrandr events.
So, what came to my mind would be :
- use srandrd to create an 'xrandr' command output cache ( simply xrandr > file.txt)
- make move-screen read this cache when available
I don't know if you already tried something to improve speed, I'll give this idea a try and let you know.
I fear it won't be as reliable as calling xrandr each time, maybe would then need another argumebnt to force ignore cache file ... things like that.
Here's te project I refer to : https://github.com/jceb/srandrd/
I use it to call a script that dumps xrandr to $HOME/.cache/xrandr.cache
then added this in the python file
import os.path
from pathlib import Path
....
home_dir = str(Path.home())
xr_cache = home_dir+"/.cache/xrandr.cache"
if os.path.isfile(xr_cache):
with open(xr_cache, 'r') as f:
out = f.read()
else:
out = subprocess.check_output(['xrandr']).decode('ascii', 'ignore')
I will probably have problems if cache file is not entirely written, and this would be better of with exception handling just in case.
But so far, so good : works reaaly great you should try it ;)
Hi @squalou without reading your issue before I implemented something similar in #16 Of course you approach would have the benefit of not using a "stale" xrandr cache as this gets updated by your dump script