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

From: Hiltjo Posthuma <hiltjo_AT_codemadness.org>
Date: Wed, 10 Feb 2021 13:57:02 +0100

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,
> > > https://lists.suckless.org/dwm/0809/6775.html
> > > 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:
> >
> > https://git.suckless.org/dwm/commit/3d1090ba896319368c4771b88d325fcee368a608.html
> >
> > 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:
https://git.suckless.org/dwm/file/dwm.c.html#l1334

-- 
Kind regards,
Hiltjo
Received on Wed Feb 10 2021 - 13:57:02 CET

This archive was generated by hypermail 2.3.0 : Wed Feb 10 2021 - 14:00:11 CET