From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: make-pointer-invisible on Windows Date: Sun, 28 Jun 2015 17:51:20 +0300 Message-ID: <83wpyn6g47.fsf@gnu.org> References: <558A75C6.7040003@gmx.at> <83zj3pdusu.fsf@gnu.org> <558AEB8D.4070603@gmx.at> <83k2usewtv.fsf@gnu.org> <558BA156.6090508@gmx.at> <83a8vnesqm.fsf@gnu.org> <558CF75E.90801@gmx.at> <83wpyqdflh.fsf@gnu.org> <558D181A.4070402@gmx.at> <83twtudd0i.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1435503107 22976 80.91.229.3 (28 Jun 2015 14:51:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jun 2015 14:51:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: rudalics@gmx.at Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 28 16:51:40 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z9Dvo-0002yf-DO for ged-emacs-devel@m.gmane.org; Sun, 28 Jun 2015 16:51:40 +0200 Original-Received: from localhost ([::1]:39154 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9Dvn-0000vP-U6 for ged-emacs-devel@m.gmane.org; Sun, 28 Jun 2015 10:51:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9Dvb-0000vK-5u for emacs-devel@gnu.org; Sun, 28 Jun 2015 10:51:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9DvW-00051B-8U for emacs-devel@gnu.org; Sun, 28 Jun 2015 10:51:27 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:36914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9DvW-0004zf-0G for emacs-devel@gnu.org; Sun, 28 Jun 2015 10:51:22 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NQN00L00SVAVO00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sun, 28 Jun 2015 17:51:19 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NQN00LVYT9JMU70@a-mtaout20.012.net.il>; Sun, 28 Jun 2015 17:51:19 +0300 (IDT) In-reply-to: <83twtudd0i.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:187612 Archived-At: > Date: Fri, 26 Jun 2015 12:39:41 +0300 > From: Eli Zaretskii > Cc: emacs-devel@gnu.org > > I understand what happens on XP: Windows sens us the WM_PAINT > messages, which the input thread picks up and passes to the main > thread. But the main thread is busy-waiting inside waitpid, so it > doesn't react to those messages until the subprocess exist. > > What I don't understand is how come the frame _is_ redrawn on Windows > 7, and that's something I still need to look into. No mystery here, it turns out. On XP, we get the WM_ERASEBKGND message when (portions of) the Emacs frame previously covered by other windows are uncovered. In response, we erase the rectangle specified by the message, and we do that from the input thread, i.e. this works even if the main thread is busy. WM_ERASEBKGND is immediately followed by WM_PAINT, but the latter is passed for execution by the main thread, and that thread is busy. This is why you wind up with an empty rectangle. On Windows 7, neither WM_ERASEBKGND nor WM_PAINT are sent, except when the Emacs frame is moved or resized. So we don't erase the rectangle, and the text remains on screen. > It might mean there is a way of keeping the frame display updated > after all. Not an easy one: we'd need to handle several expose events for different rectangles at once. Given that X doesn't support this, I see no reason to invest any efforts there.