From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: MS Windows double buffering Date: Sat, 30 Apr 2022 15:46:43 +0800 Message-ID: <87v8urt3mk.fsf@yahoo.com> References: <877d791thh.fsf.ref@yahoo.com> <877d791thh.fsf@yahoo.com> <83ilqtbl3p.fsf@gnu.org> <87sfpxz8a7.fsf@yahoo.com> <87mtg4zhlg.fsf@yahoo.com> <87mtg3unzu.fsf@yahoo.com> <835ymr9i9v.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25366"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: Ken Brown , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 30 09:48:55 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkhqZ-0006Tj-1h for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Apr 2022 09:48:55 +0200 Original-Received: from localhost ([::1]:35892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkhqW-00030K-GK for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Apr 2022 03:48:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43404) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkhoj-0002IM-7l for emacs-devel@gnu.org; Sat, 30 Apr 2022 03:47:01 -0400 Original-Received: from sonic301-30.consmr.mail.ne1.yahoo.com ([66.163.184.199]:43445) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nkhog-0006kV-K4 for emacs-devel@gnu.org; Sat, 30 Apr 2022 03:47:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651304816; bh=oM5fNxJub4cXlB2VLdDKwz9LcijVJbcWHaMv8Dc70qE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=ELpQcVWdb7znkwAYqRA6PVsWQn7+FbHSl8NLHEWu/ltD9yZFhcURxuuad0yZmVBVMvSYAZdF+8NDZ9gFdxgEiPd+YEfZ5lUygFAt+2ppiwQzVC4rKNq72diogdTI/c+/JQY7TtlfHVS4zt1LH2b1KnW14hs/1cqSijlVXr484BtT67ZxPxWcebpV/zNqoOeYNiWWhSUNIGNSfm03iiwFNH17fvdtsbZavV/3z8jrTOUnC2RqfPU9FBDGIRA5Bc6+a80aTFETlCnnuGj8ZQApxk2SO6Xn5I2qid+Mc7PULzr+TES5mQz2diqkQ3gwZBpmSS0cp7HYHAxD9klzrAdoew== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651304816; bh=0F2f1xqcjT0YhBtTZZrh2/qBP4J0KNdr/gctWngAKZb=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=OGVcbzRKOhsNot8e4mGqK/G1gkZjli0xo0R3bU2GAoBKSBtHdo4boIXlKczrDM3KIxoRqYh3dnQTWA1dE8yEJJIwGC7/ohFf5UObpAfuKEQGyKjfTx2yLAeqJ5L2HMHej113w7fTTAxvas5jQLac+Qv6hMcaNMuOHY9fkxlBd8GHEA30iYXDBaiEqSjrF8NXvKwHAp9sc3C+ylTmdqiQ27Feo+E3njnd7TDa41uMoqou6NW9+gn2UFNRptB88WoRC9yhQpY1NFIoCtZcTXYbCm7c7qqni0sFSkE/bFnwytuJkh3EAb2rEk5GEW+A+C2BrZjK1o6fxOeE5oL9uEpBFA== X-YMail-OSG: MM4DNC4VM1nbjbYCx09CiW2aGfzh851_Wqd6nlWFXX43qfxIINIQGvQ7VDSTg4F T7sHLWRLBpYVOOnF5RhhCSz6p_oRSstnCQFtAblFkuUaYOWy0TWVz_k90QVwaK4f00hLPjSKHkQh aR_5PxyDupbUwXRe0Ox90domMCkMBB264s_DtFJPRq3gpQRkMMQlqeDjsVq6NFAn8d8VeyzVYrrh 7wiDpTMvUGJcDUgHKhyhZst0Aljf291mVhalIzK.EOlJWCF8wijTmlErkPpmGXulnwLMDOZ9nZTn 7BIqOyIKh7YUzo1R2N2a510pmlvhsrqg9yVqiLdB9O4MY1tGsTwfAmtBHwdhbNvYlBvlqr1j1SxD eAOON9O6jMstjV1pQ9fhN7n_xZ7Vn.dgO44aCeoGwgBtSLDzkpwzwuXxzW5UzJaqPKCk5OQFKHQy HMCLUQiJTVATAc32Jd7ZnStt6LxnbPVBB18sTl231Sscb04Zua7FfmiAyws6DKTM.gHwRyxzMaJH DkmdKnf2zsYul1sAyiHKJUVusIz1JflDap4wECo9A3cZy5PTuBkrNJNABRCH_o02AktIvbZPUDlw EZ2Bp4JIukYuGba.5GqKX2e1V8Hj9nMVTC0nveEaX_UmR0g7iWoUnF5z9f.ItlRAmxymuLFABRGr _GTNE.7dAsnEDjhwFOBl.pORPVtMPlHmqnWpEUK5s3IkPcW0dCCjNq1gHgFBYvotjNmzwHQAu.G_ FAnJQdWSjO3YFSFrXRXqzv9tkP_Smg9gqjkP.be70rNI3SOoQ4Vn7rgdKZS.y9nJ7mH5POUr01r1 HOyifI3LrWvRo_cFfU1hxr2527RMZ5yqTiZiCKbzQR X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Sat, 30 Apr 2022 07:46:56 +0000 Original-Received: by hermes--canary-production-sg3-795d7b4d54-hch72 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cc4ac77f8a245b5d46b4a81d765e99e4; Sat, 30 Apr 2022 07:46:49 +0000 (UTC) In-Reply-To: <835ymr9i9v.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Apr 2022 09:50:36 +0300") X-Mailer: WebService/1.1.20118 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.184.199; envelope-from=luangruo@yahoo.com; helo=sonic301-30.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:289036 Archived-At: Eli Zaretskii writes: > However, I don't understand why you went ahead without waiting for the > review of the patches you posted. What's the rush? The result can be > only one: the changeset is spread on a larger set of commits, and > makes it harder to understand what changed and why, when later these > questions are asked. > > Please don't act as if we are under some time pressure when we really > aren't. I will keep that in mind in the future, sorry. > The old_value argument is unused, which should at least be mentioned, > if not marked with an explicit "unused" attribute. > > Also, this function is a frame redisplay-interface method, so it > should have a comment describing its functionality. I will write one, thanks. > These two functions should do nothing and return immediately if > double-buffering is disabled. They currently will try to enter the > critical section before returning, which is an unnecessary slowdown. > At least w32_release_paint_buffer is called also when double-buffering > is disabled, AFAIU, so it should return immediately in that case. w32_release_paint_buffer releases the back buffer bitmap when a back buffer exists. It is only called if double buffering is enabled, or when double buffering is being turned off, or during frame resize (to resize the back buffer bitmap.) But w32_show_back_buffer should indeed work that way, yes. > Here and elsewhere in the modified code, I'd like to have all the > changes that affect the no-double-buffering code to be conditioned on > some variable exposed to Lisp. That way, if and when someone reports > a problem that could be related to this feature, we could easily get > back to exactly the old code as it was before the changeset, and see > if the problem is indeed due to this change. For example, entering > the critical section above is one such change. Thanks. That's not something we do on X, but I will add such a variable. > This function, which is an important part of redisplay, was basically > rewritten from scratch. As explained above, please add back the > deleted old code, conditioned under the variable I described there, so > that we could test whether the new code is responsible for some > problem that users may report. [...] > There should be a comment here explaining why we return in that case. Likewise, I will do that. > I don't understand why you enter the critical section here: > w32_show_back_buffer does that internally, and the old code didn't > need that. `paint_buffer' can only be accessed safely inside the critical section, as long as get_frame_dc can be called from the message pump thread, but maybe it isn't called there. > This is not clean, since it references a WM_ message in a place other > than where its main processing happens. Please change it so > processing of WM_WINDOWPOSCHANGED raises some flag (which is otherwise > always false), and have this code here test that flag. Will do, thanks. > This looks like whitespace change? Or did I miss something? Sorry for that, it snuck in somehow. > And two more general issues: > > . w32term.c is also used in the Cygwin w32 build, (which produces a > Cygwin Emacs that uses the native MS-Windows GUI functions instead > of X). Will this code work in that build? If not, the new code > should be ifdef'ed away on Cygwin. Ken, can you please chime in > and help us DTRT here? No idea, though I don't think double buffering uses anything that might not work on Cygwin. > . how does one test this feature? I rarely see any flickering on > MS-Windows, so what should I try to see the effect of double > buffering in action? Emacs should flicker much less (or not at all) upon any of the test cases in the last thread(s) on flicker, or when you run this: (while t (redraw-display) (redisplay)) Thanks.