When monitors are removed, the coordinates of existing monitors may
change, if the removed monitors had smaller coordinates than the
remaining ones.
Remove special case handling so that the same update-if-necessary loop
is run also in the case when monitors are removed.
ref.
https://git.suckless.org/dwm/commit/d93ff48803f04f1363bf303af1d7e6ccc5cb8d3f.html#h0-0-21
This patch defers all size hint calculations until they are actually
needed, drastically reducing the number of calls to updatesizehints(),
which can be expensive when called repeatedly (as it currently is during
resizes).
In my unscientific testing this reduces calls to updatesizehints() by
over 90% during a typical work session. There are no functional changes
for users other than an increase in responsiveness after resizes and
a reduction in CPU time.
In slower environments or X servers, this patch also offers an
improvement in responsiveness that is often tangible after resizing a
client that changes hints during resizes.
There are two main motivations to defer this work to the time of hint
application:
1. Some clients, especially terminals using incremental size hints,
resend XA_WM_NORMAL_HINTS events on resize to avoid fighting with the
WM or mouse resizing. For example, some terminals like urxvt clear
PBaseSize and PResizeInc during XResizeWindow and restore them
afterwards.
For this reason, after the resize is concluded, we typically receive
a backlogged XA_WM_NORMAL_HINTS message for each update period with
movement, which is useless. In some cases one may get hundreds or
thousands of XA_WM_NORMAL_HINTS messages on large resizes, and
currently all of these result in a separate updatesizehints() call,
of which all but the final one are immediately outdated.
(We can't just blindly discard these messages during resizes like we
do for EnterNotify, because some of them might actually be for other
windows, and may not be XA_WM_NORMAL_HINTS events.)
2. For users which use resizehints=0 most of these updates are unused
anyway -- in the normal case where the client is not floating these
values won't be used, so there's no need to calculate them up front.
A synthetic test using the mouse to resize a floating terminal window
from roughly 256x256 to 1024x1024 and back again shows that the number
of calls to updatesizehints() goes from over 500 before this patch (one
for each update interval with movement) to 2 after this patch (one for
each hint application), with no change in user visible behaviour.
This also reduces the delay before dwm is ready to process new events
again after a large resize on such a client, as it avoids the thundering
herd of updatesizehints() calls when hundreds of backlogged
XA_WM_NORMAL_HINTS messages appear at once after a resize is finished.
ref.
https://git.suckless.org/dwm/commit/8806b6e2379372900e3d9e0bf6604bc7f727350b.html#h0-0-4
In certain instances trans may be set to a window that doesn't actually
map to a client via wintoclient; in this case it doesn't make sense
to set isfloating/oldstate since trans is essentially invalid in that
case / correlates to the above condition check where trans is set /
XGetTransientForHint is called.
Ref.
https://git.suckless.org/dwm/commit/bece862a0fc4fc18ef9065b18cd28e2032d0d975.html
+ when moving window from monitor with different tags selected the moved
window would not get the tags set properly if multiple windows are
already on that monitor
This is achieved by adding the -Wno-unused-function flag to the compiler.
The warnings are suppressed to avoid confusion for users new to dwm.
Removing the static declaration from the header files works too, but adds
unnecessary data into the compiled object.
I noticed that a non-trivial amount of dwm's work on my machine was from
drw_text, which seemed weird, because I have the bar disabled and we
only use drw_text as part of bar drawing.
Looking more closely, I realised that while we use m->showbar when
updating the monitor bar margins, but don't skip actually drawing the
bar if it is hidden. This patch skips drawing it entirely if that is the
case.
On my machine, this takes 10% of dwm's on-CPU time, primarily from
restack() and focus().
When the bar is toggled on again, the X server will generate an Expose
event, and we'll redraw the bar as normal as part of expose().
Ref. https://git.suckless.org/dwm/commit/8657affa2a61e85ca8df76b62e43cb02897d1d80.html
This is achieved by adding the -Wno-unused-function flag to the compiler.
The warnings are suppressed to avoid confusion for users new to dwm.
Removing the static declaration from the header files works too, but adds
unnecessary data into the compiled object.
I noticed that a non-trivial amount of dwm's work on my machine was from
drw_text, which seemed weird, because I have the bar disabled and we
only use drw_text as part of bar drawing.
Looking more closely, I realised that while we use m->showbar when
updating the monitor bar margins, but don't skip actually drawing the
bar if it is hidden. This patch skips drawing it entirely if that is the
case.
On my machine, this takes 10% of dwm's on-CPU time, primarily from
restack() and focus().
When the bar is toggled on again, the X server will generate an Expose
event, and we'll redraw the bar as normal as part of expose().
Ref. https://git.suckless.org/dwm/commit/8657affa2a61e85ca8df76b62e43cb02897d1d80.html
consideration when deciding whether or not to allow dwm to quit
As per the original patch
https://dwm.suckless.org/patches/onlyquitonempty/
it used XQueryTree to get a count of the number of windows open to
determine whether to allow the window manager to exit.
This meant that the empty quit count variable would have to take
into account background windows such as the bar, which has side
effects like plugging in another monitor could mean that you would
not longer be allowed to quit dwm until the monitor is removed.
Likewise a systray and each systray icon would give a +1 to the
number of windows in the system.
This is unintuitive to understand and convoluted to explain, hence
the refactoring here to use the more sane approach of only counting
the number of client windows that the window manager manages.
This is an old idea which was intentionally not added to
dwm-flexipatch due to the aim of staying true to the original patch
(as in if you were to patch that manually you would get the same
experience as you had when trying the patch out in dwm-flexipatch).
This is ref. discussion in #194.
