| commit | 8657affa2a61e85ca8df76b62e43cb02897d1d80 | |
| author | Chris Down <chris@chrisdown.name> | |
| Sat, 18 Dec 2021 16:58:23 +0000 (18 16:58 +0000) | ||
| committer | Hiltjo Posthuma <hiltjo@codemadness.org> | |
| Sun, 19 Dec 2021 15:16:30 +0000 (19 16:16 +0100) | ||
| tree | 278fac042ed0989747aea5a80b8f1f5e92db4efa | treesnapshot (tar.gz zip) |
| parent | a786211d6cb794fba0ea406d86002c7618998afc | commitdiff |
drawbar: Don't expend effort drawing bar if it is occluded
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().
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().
| dwm.c | diffblobblamehistory |