From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=DATE_IN_PAST_12_24 autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 16112 invoked from network); 16 Oct 2021 09:17:36 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 16 Oct 2021 09:17:36 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 4ess; Fri Oct 15 07:20:35 -0400 2021 Message-ID: Date: Fri, 15 Oct 2021 13:20:25 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: transactional framework dependency session-scale frontend Subject: Re: [9front] [drawterm] Wayland support and misc patches Reply-To: 9front@9front.org Precedence: bulk > Also I am not sure why there was a sleep within the > kern/term.c:/^resizeproc/ loop, but I noticed the delay > when working on the wayland backend. There is a patch for > removing that sleep. it is for debouncing. that is, when we get a zillion window resize events per second (which can happen with some window managers), we do not want to flood that to the remote side as it is a very expensive operation in devdraw model, as every graphical program needs to be notified and re allocate a its screen and then redraw. so with the sleep, we limit the rate of devdraw resize to once per second. also note the location of the delay. it will do the first resize *immediately*. but then wait at least a second until we check if it got resized again. so this is only affecting window managers that continuously generate resize events for the window. -- cinap