GNU bug report logs - #75056
31.0.50; tty-child-frames with server / multiple clients possible hangs

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
Subject: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs
Date: Sun, 26 Jan 2025 10:10:08 +0100

martin rudalics <rudalics <at> gmx.at> writes:

> I still wonder what happened to the "when one frame completely obscures
> another" visibility state issue.  Has that vanished?  IIUC it would make
> a child frame (and possible even a root frame) practically invisible
> when no part of its drawn by redisplay.  On a GUI the WM would decide
> that and we don't have to care (IIRC we did care on Windows in the past
> - at least when debugging).

I can't claim that I understand completely what the problem was/is, but
here is the situation on ttys:

On ttys, child frames which are invisible are not copied to the frame's
desired matrix, so they disappear. If children are obscured by others
is handled by copying in reverse z-order, from bottom to top. No
smartness invested in determining if we can avoid copying a child
because it is obscured by another. 

Above combine_updates, in the glyph generating code, child frames are
handled completely independent of each other, as if they were the sole
frame on their own terminals. So no obscuring, nothing of that sort.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.