From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: RFC: flicker-free double-buffered Emacs under X11 Date: Thu, 27 Oct 2016 12:56:41 -0700 Message-ID: <965a0fad-3e19-a72a-694b-558816ae23e0@dancol.org> References: <9e8ad090-a6a0-c807-95ae-7ec7c3f391cb@dancol.org> <83k2d2rssf.fsf@gnu.org> <831sz9sime.fsf@gnu.org> <83y41hqz94.fsf@gnu.org> <838tte5fzq.fsf@gnu.org> <740d34db48a1e4b711cb1cfa987423c9.squirrel@dancol.org> <831sz1twhn.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1477598459 26210 195.159.176.226 (27 Oct 2016 20:00:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Oct 2016 20:00:59 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 Cc: raeburn@raeburn.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 27 22:00:53 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzqqj-0003LO-Er for ged-emacs-devel@m.gmane.org; Thu, 27 Oct 2016 22:00:29 +0200 Original-Received: from localhost ([::1]:44266 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzqqm-000247-1t for ged-emacs-devel@m.gmane.org; Thu, 27 Oct 2016 16:00:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzqnA-00007Y-VI for emacs-devel@gnu.org; Thu, 27 Oct 2016 15:56:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzqn7-00025k-TL for emacs-devel@gnu.org; Thu, 27 Oct 2016 15:56:49 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:35066) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bzqn7-00025b-Ll; Thu, 27 Oct 2016 15:56:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=yq9NGemy47CTFtsl8Rg/AsyP46eRL/peDxGjzxfcQ5k=; b=V5JcNpdWQ2CibGSxTqVw3D5nObDGhlJGixj93D93NvjOKp85O60fO5VSWvJJpGqLfhubuTlvxfaUPSDqIOVmpVOUoVdTyTutOR6J/Ee+T/rtQyL5IM9zNKQMB/tLLzgshSLDaCWNE/UYc+UqVwSIWJleWyLE3xEbvQsZpTINxeLWgp1Z46oriAwMN2IKsIUVSnwHSQECLRiCrqgIYOpCCG0NfxmCxuIbuqoOl2hgmjND/AU6APzFHU94MOkzxaGyMQ2STuVjouoYoFLcFMXW1BDWh9AAr9a2tGyhDa10tPuHC4tS+x8/wE/ObTb+HcJr+8xXnonseM0YLCHkCwc2kg==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bzqn6-0007y3-O2; Thu, 27 Oct 2016 12:56:44 -0700 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:208888 Archived-At: On 10/27/2016 12:44 PM, Daniel Colascione wrote: > On 10/27/2016 12:36 PM, Eli Zaretskii wrote: >>> Date: Thu, 27 Oct 2016 12:06:25 -0700 >>> From: dancol@dancol.org >>> Cc: Daniel Colascione , Ken Raeburn >>> , >>> emacs-devel@gnu.org >>> >>> Below is a new much-improved version of the patch. It should address the >>> legibility concerns while probably adding more. It addresses all the >>> bugs >>> I've been able to find and on my machine, produces buttery smooth >>> editing >>> and resizing. >> >> Thanks. >> >>>>> Why _do_ we have a path that short-circuits the rest of the redisplay >>>>> code? What would happen if we just removed it? It appears to be some >>>>> kind of optimization, and I'm not sure it's actually necessary >>>>> (especially since, according to the comment, we disable it anyway >>>>> in the >>>>> case of a blinking cursor). >>>> >>>> It's an optimization for the case that nothing needs to be >>>> redisplayed. >>> >>> Isn't the "goto update" path fast enough? >> >> That would still call hscroll_windows and update_frame, which is just >> waste of cycles when we know nothing's changed. >> >>> @@ -14072,6 +14072,17 @@ redisplay_internal (void) >>> if (!f_redisplay_flag && f->redisplay) >>> goto retry_frame; >>> >>> + /* In some case (e.g., window resize), we notice >>> + only during window updating that the window >>> + content changed unpredictably (e.g., a GTK >>> + scrollbar moved) and that our previous estimation >>> + of the frame content was garbage. We have to >>> + start over. These cases should be rare, so going >>> + all the way back to the top of redisplay should >>> + be good enough. */ >>> + if (FRAME_GARBAGED_P (f)) >>> + goto retry; >> >> This worries me a bit: FRAME_GARBAGED_P returns non-zero for TTY >> frames very frequently, whereas at least the comment seems to imply >> this is needed only for GUI frames, perhaps even only in GTK builds. >> If that is correct, then perhaps add a FRAME_WINDOW_P test here, to >> avoid unnecessarily slowing down redisplay. > > Sure. > By the way: why would we ever _want_ to allow redisplay to return without having redrawn all garbaged frames? The design of redisplay suggests that a postcondition on redisplay_internal should be that there's nothing left to draw, at least in the case that we weren't interrupted by input.