From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MS Windows double buffering Date: Sat, 30 Apr 2022 12:10:14 +0300 Message-ID: <83v8ur7x8p.fsf@gnu.org> 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> <87v8urt3mk.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11739"; mail-complaints-to="usenet@ciao.gmane.io" Cc: kbrown@cornell.edu, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 30 11:13:02 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 1nkj9x-0002st-Qg for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Apr 2022 11:13:02 +0200 Original-Received: from localhost ([::1]:59470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkj9w-0005r8-HK for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Apr 2022 05:13:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52298) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkj7I-0004vh-Nr for emacs-devel@gnu.org; Sat, 30 Apr 2022 05:10:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41758) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkj7H-0000oY-2B; Sat, 30 Apr 2022 05:10:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rZ5pzla9433cu8xatrDT58SGyHOZyIjVWZIiY4CDcEc=; b=arnVQaozRT8b ypz3hq6ZQlu2hOkZp+NM5RxX34jJVgQ3bPguH7bOGljO3VvMzYmqjQqGhWVYUPsZo9cIABNQ338XF R+cy8oAk4WzmCboMJh8pfsViCJBRbyVsWp3VTPpGf9vRe9qRtg1JMzQB0SvripLLUcRmwiCNemSh6 WpGThsLBDSBjPEf9buf18sWIll67iIf1/0GKBeJJHD3PqyZKOn7E9kKCU2QZ4M4KQOnURHMbLefN2 vJ27Yy6A8V59wt553STPs8jMq4zsiriW3tn7cJg7iZCMoDnAZ69yNE2g0vnxQtOAifiTjiBSKbCTb EkG9hLCAjU/N0tdGUratkA==; Original-Received: from [87.69.77.57] (port=4471 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkj7D-0006aK-Nz; Sat, 30 Apr 2022 05:10:14 -0400 In-Reply-To: <87v8urt3mk.fsf@yahoo.com> (message from Po Lu on Sat, 30 Apr 2022 15:46:43 +0800) 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:289039 Archived-At: > From: Po Lu > Cc: Ken Brown , emacs-devel@gnu.org > Date: Sat, 30 Apr 2022 15:46:43 +0800 > > > 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. Emacs is being tested on X much more than on MS-Windows, and people who use it on X tend to be more knowledgeable about the technical issues than a typical user of Emacs on Windows. Moreover, the level of expertise we have on our team about Windows-specific GUI aspects is significantly lower than in the X case. So having such a debugging device for significant changes in display code is beneficial. > > 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. So you are saying this code didn't work correctly before? Or am I misunderstanding something? > > . 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. Let's hope Ken will help us here. > > . 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)) This still flickers considerably here, albeit with a significantly lower frequency. What other test cases in the discussions would you recommend to try?