From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-043.btinternet.com (mailomta7-sa.btinternet.com [213.120.69.13]) by sourceware.org (Postfix) with ESMTPS id 3E1F43858D28 for ; Sat, 30 Apr 2022 15:25:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3E1F43858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from sa-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.38.5]) by sa-prd-fep-043.btinternet.com with ESMTP id <20220430152527.HNME3164.sa-prd-fep-043.btinternet.com@sa-prd-rgout-002.btmx-prd.synchronoss.net>; Sat, 30 Apr 2022 16:25:27 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 6139417C2196D3F6 X-Originating-IP: [86.139.167.41] X-OWM-Source-IP: 86.139.167.41 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvfedrvddugdekkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepffekiefgudejheetudeigfejledtleegleetkeduteeftdfffefhueefgfeutedtnecukfhppeekiedrudefledrudeijedrgedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddutdehngdpihhnvghtpeekiedrudefledrudeijedrgedupdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdpnhgspghrtghpthhtohepvddprhgtphhtthhopegthihgfihinhestgihghifihhnrdgtohhmpdhrtghpthhtohepshhjrghluhhosehgmhgrihhlrdgtohhm X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.105] (86.139.167.41) by sa-prd-rgout-002.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 6139417C2196D3F6; Sat, 30 Apr 2022 16:25:27 +0100 Message-ID: Date: Sat, 30 Apr 2022 16:25:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Window flickering problem in XWin multiwindow mode Content-Language: en-GB To: "S.J. Luo" , The Cygwin Mailing List References: From: Jon Turney In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1194.5 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2022 15:25:29 -0000 On 26/04/2022 04:53, S.J. Luo wrote: > I have some EDA tools running on a Linux machine and display on my Windows > PC using xorg-server-21.1.3 XWin multiwindow mode > Sometimes the application window flickers forever for an unknown reason. > The problem became more severe after my PC upgrade to Windows10. > > Googling the problem, I did not find such issue reported. > I decided to take advantage of open source nature and solve it by myself. > After re-compiling and debugging, I found a calling loop triggered. > Here I eliminate the detail of the cause. I may write later if someone requires. > > Knowing the root cause, I am now able to demonstrate the issue with a small > test case as well as a patch that works for me. Both are attached below. Thanks very much for taking the time to look into this, and writing a patch. I will apply it. But I'd like to add a bit more commentary, which perhaps you can supply, about the analysis you did to determine: 1. how the code is misbehaving 2. how this change remedies that 3. how this change doesn't effect anything else What your fix does is examine the queue of pending WM messages to determine if there are any more pending for the window receiving a WM_WM_CHANGE_STATE message, and if there are, ignore it. It seems to me that is error prone, in a couple of ways: 1. it should check the message type as well, as e.g. a pending message of a different type could cause a WM_WM_CHANGE_STATE message to be ignored. 2. even then, assuming that successive WM_WM_CHANGE_STATE messages cancel out each other isn't always true e.g. consider a sequence of _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_VERT followed by _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_HORZ. If you were to send other patches in future, please send them as attachments, or even better, using git format-patch/git send-email, as that makes it much easier to apply them without white-space damage and with correct attribution.