re-evaluate switch from event based operation
ZimbiX opened this issue · 4 comments
There is a slight delay where the window is its initial size/position before Smart Auto Move changes it. This applies to non-maximised windows (it seems that Gnome remembers the maximised state by itself; so that's fast). In coming from Maxi, I was expecting the resize to be quicker.
I can see that this extension uses polling, from playing with the 'sync frequency' setting (when setting this to 5000ms, there can be a few seconds before a new window is resized), and looking at the source. I tried reducing the polling interval from the default of 100ms, but it has a minimum of 50ms, which does not eliminate the stutter. At that polling rate, the CPU use of gnome-shell is ~10% higher than with the extension disabled, which is not great.
Would it be possible to switch over to being event-based? Maxi is event-based, but that only has to listen for window creation, not also having to deal with saving window sizes; but perhaps there are resize/maximise/unmaximise events?
Thanks for making this extension =)
I think I found the docs for the necessary signals:
thank you for the suggestion, @ZimbiX
the first implementation of smart-auto-move actually used this strategy. you can see the change that started to move away from signal based window management here: 00c189e
there are limitations with the shell extension framework that made it problematic. in particular, if you change the properties of a window inside of an event instead of in the mainloop, they do not hold.
from the original documentation: "changing a window's frame rect inside of [the windows-changed] handler does not actually move the window, so it instead needs to happen in the Mainloop." -- which also required an arbitrary timeout.
managing this inconsistency resulted in some race conditions and technical debt, so i switched to the polling method.
Interesting. Thanks for the context!
It looks like Maxi waits on a subsequent event, focus before maximising - would that help? Or does maximising not have the same restrictions as resizing?
On the saving side of things, was there a reason that needed to use polling too?