Re: [dev] [dwm] Hide window content when moving/resizing windows

From: Κράκ Άουτ <>
Date: Wed, 10 Feb 2021 16:31:17 +0200

Στις 10/2/21 2:57 μ.μ., ο/η Hiltjo Posthuma έγραψε:
> On Wed, Feb 10, 2021 at 01:10:40PM +0200, Κράκ Άουτ wrote:
>> Στις 10/2/21 12:34 μ.μ., ο/η Hiltjo Posthuma έγραψε:
>>> On Wed, Feb 10, 2021 at 10:40:39AM +0200, Κράκ Άουτ wrote:
>>>> I started using dwm a couple of months ago, switching from xfce4. Since
>>>> my pc is a bit constrained on resources I really appreciate the low
>>>> memory footprint of dwm. But I've noticed that it's slower than
>>>> xfce/xfwm when resizing/moving floating windows. Also on converting
>>>> tiled to floating and vice-versa (equivalent to unmaximize/maximize on
>>>> xfwm).
>>>> Regarding driver and general X setup everything is fine, 3D graphics, hw
>>>> assisted video playback work ok. I've pinned down the speed difference
>>>> to xfwm's option to hide contents of windows when moving and resizing,
>>>> which I've enabled on xfwm. Only the frame of the window is drawn, until
>>>> the final position when the hole window draws back again.
>>>> I've searched for dwm patches with equivalent functionality, haven't
>>>> found anything. Do you have any idea how to achieve hiding content of
>>>> windows when moving and resizing on dwm?
>>>> I've also met this,
>>>> I quote, "Some people mentioned that mouseresize is really slow in dwm".
>>>> Apparently others have noticed this lag also. In this mail there is a
>>>> patch/hack, but it's some years old, I tried to patch my dwm setup with
>>>> it, didn't make it.
>>>> I suppose for a light, hackable wm like dwm, it would be nice to have an
>>>> option or a patch to hide window content when moving/resizing windows.
>>>> It makes a difference on older hardware.
>>> Hi,
>>> Can you describe more precisely what is felt as "slow" to you? Some numbers
>>> would be nice.
>>> What are the exact specifications of your machine, related to video drivers,
>>> memory etc?
>>> This commit was added after 2008 as a fix/workaround. It limits updates to
>>> ~60fps:
>>> At the time I think the lag was introduced after a X11 change related to the
>>> graphics stack on my machine, but I'm not entirely sure.
>>> I think it would be nice to have this patch anyway, either as a wiki-patch or
>>> maybe even upstreamed if it is simple enough.
>> Hi Hiltjo,
>> It's not slow in the sense that it's not usable, but obviously not as
>> fast as not drawing contents at all. Unfortunately I have no way to
>> benchmark and provide numbers; it doesn't take a sec or more to move a
>> floating window, it's just a bit sluggish.
>> To clarify, the same sluggishness applies for xfwm, if I enable it to
>> show the contents of windows while moving/resizing. I do not consider
>> dwm to fall short or have a bug, it's just that I cannot disable showing
>> windows contents on move/resize, as in other window managers.
>> My pc is an 11 year old Intel i3 cpu, Ati Radeon HD 2000.
> The general specs should be fine.
>> So, looking at your code, can I limit updates to 1/sec instead of
>> 60/sec? Changing this line,
>> `if ((ev.xmotion.time - lasttime) <= (1000 / 60))`
>> to
>> `if ((ev.xmotion.time - lasttime) <= (1000 / 1))`
>> would be enough?
> You could try it and see if it's an OK workaround for your use-case. It would
> of course have a trade-off of not updating as frequently showing the new
> geometry.
>> Can I also achieve 0/sec somehow? I suggested 1/sec because division by
>> zero is not possible.
>> Forgive me if the proposal it totally wrong, I'm not into C at all.
> You could change the event loop and set some flag, then update the geometry
> after processing the events. It would not give any visual feedback then however
> (with the current logic).
> In resizemouse() around here:

I experimented a bit, finally I set the limit to 20 times per sec.
Movement is a bit rough, but faster; I prefer it that way. I'll try
changing the event loop in the future. I need to study first :)

Thank you very much Hiltjo!
Received on Wed Feb 10 2021 - 15:31:17 CET

This archive was generated by hypermail 2.3.0 : Wed Feb 10 2021 - 15:36:10 CET