From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#38731: [PATCH] Calculate first glyph to be redrawn when exposing (bug#38731) Date: Sat, 28 Dec 2019 11:20:13 +0000 Message-ID: <20191228112013.GA93177@breton.holly.idiocy.org> References: <20191227143500.GA75733@breton.holly.idiocy.org> <20191227162620.GA92799@breton.holly.idiocy.org> <83a77dpu28.fsf@gnu.org> <20191227190652.GA92850@breton.holly.idiocy.org> <83v9q0omn9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="97343"; mail-complaints-to="usenet@blaine.gmane.org" Cc: netjune@outlook.com, 38731@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 28 12:21:19 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ilA9n-000PAY-5y for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Dec 2019 12:21:19 +0100 Original-Received: from localhost ([::1]:42614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilA9l-0000dR-V0 for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Dec 2019 06:21:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44302) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilA9X-0000d9-QC for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 06:21:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ilA9W-0001tj-ES for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 06:21:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52018) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ilA9W-0001sb-6e for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 06:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ilA9W-0001Qn-1l for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2019 06:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Dec 2019 11:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38731 X-GNU-PR-Package: emacs Original-Received: via spool by 38731-submit@debbugs.gnu.org id=B38731.15775320295457 (code B ref 38731); Sat, 28 Dec 2019 11:21:02 +0000 Original-Received: (at 38731) by debbugs.gnu.org; 28 Dec 2019 11:20:29 +0000 Original-Received: from localhost ([127.0.0.1]:57991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilA8v-0001Pr-Oc for submit@debbugs.gnu.org; Sat, 28 Dec 2019 06:20:29 -0500 Original-Received: from mail-wm1-f49.google.com ([209.85.128.49]:38463) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ilA8t-0001Pd-2w for 38731@debbugs.gnu.org; Sat, 28 Dec 2019 06:20:24 -0500 Original-Received: by mail-wm1-f49.google.com with SMTP id u2so10292366wmc.3 for <38731@debbugs.gnu.org>; Sat, 28 Dec 2019 03:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=OOuWQWCAv+5swYX9EBmR3aUHQhgD+hcpg0GLZJ0jlxU=; b=kJdMeXzbBf6H9+KAjvLJke2VuKZmuyw4Z5Xy70Uw4H94yUAD22Gd7Gart1GPXnwaKA YT51hVCa/GmnUnYw8TWT4BJo7zi6+7zz2G6myd5yQ5pfC2/ryZJevjs4bdQiD77ITUSs MfUq+L6f4YIlbKMycXDjnZUEBb5Fl5fOnV7/nERDbrTxUNqJrRc21s3QTqpyr28kDnw3 3ehArc1Pzt5qNDLJAafYJxxZ18tw+VNKgSj+w1gpzt8Q4KbaqkdvQMiwHSpkvFGWVElp yGJA2P1Yw76VehsQiwBnYRM+oEr7x14UyqmbMv9e8+HJ4n3N4rOW+jRgI57Ys9gkZgGH 8w7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=OOuWQWCAv+5swYX9EBmR3aUHQhgD+hcpg0GLZJ0jlxU=; b=bcEqgP4p6bV/gbPs1eBYRqGFo5VJZ4Jc9ItoOjIqiKKF69SmZUWWZgQlm7Wu+BWRPp aDkxpl3m8z0smBtHWkzSxOvHyMtk650hVIe1hcuZAg3rvseY3h+OZVy2y1lD9oL590mB k4r3NOUF3Rsr0haxMgtCjoPQM53DxXiMpXwjLNsZE1jekj0BoR85Mc1R+Q7UgdcvB/e4 hKeE8yqa+TGBq6Wj7CtRU6RSiaTSKqEI24zoSITRbtXj2doeAfJWgv/t5az/ZwxDXcPu 5egntJs94ZxlS2truH3Cx7p0MehWcj8EMPfaXTIb11zMiml8u5MsiTPzhXA2hJGAJ6SF 64eA== X-Gm-Message-State: APjAAAUWVZQ9lcBwg9BdsDl8pK3C99VhjDASUbHMgv57FORgaNJvSFSW 2exVWTggvKApmYegdnM+kpg= X-Google-Smtp-Source: APXvYqwdDzEKix3mkvg05t9zFmTJVtCYoes0jeajwHy388sIlw4J+4nTtKAtveVA1QkfTjwaKq2UUg== X-Received: by 2002:a7b:c956:: with SMTP id i22mr23835558wml.67.1577532017185; Sat, 28 Dec 2019 03:20:17 -0800 (PST) Original-Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-5065-467f-7969-bf01.holly.idiocy.org. [2001:8b0:3f8:8129:5065:467f:7969:bf01]) by smtp.gmail.com with ESMTPSA id p15sm14061746wma.40.2019.12.28.03.20.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Dec 2019 03:20:16 -0800 (PST) Content-Disposition: inline In-Reply-To: <83v9q0omn9.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:173843 Archived-At: On Sat, Dec 28, 2019 at 10:54:50AM +0200, Eli Zaretskii wrote: > > Date: Fri, 27 Dec 2019 19:06:52 +0000 > > From: Alan Third > > Cc: netjune@outlook.com, 38731@debbugs.gnu.org > > > > The actual problem is that if there is a face that’s to extend to the > > end of the line (for example with global-hl-line-mode) then > > expose_area asks draw_glyphs to draw glyph 0 at x coordinate 0, even > > though in this case there is horizontal scrolling in effect that means > > glyph 0 should be at a negative x coordinate. > > > > In my case I could see that row->x in expose_area was set to -42 but > > expose_area called draw_glyphs with an x parameter of 0. This offset > > the glyphs on the screen by 42 pixels. I could see this both in > > debugging printfs and by actually measuring the difference between the > > cursor and the equivalent text as drawn on the screen. > > You are saying that, when the window is hscrolled, the glyphs in the > glyph row start with the glyph for the very first character of the > physical line in this case? IOW, if the line's text is "abcdef", then > row->glyphs[TEXT_AREA] is the glyph for the character 'a', even though > the line is hscrolled? > > This shouldn't happen, because display_line, the function which > produces glyphs in glyph rows, starts producing the glyphs at the > first one that is actually visible, thus taking the hscroll into > account. See the code in display_line that follows this comment: > > /* Move over display elements that are not visible because we are > hscrolled. This may stop at an x-position < first_visible_x > if the first glyph is partially visible or if we hit a line end. */ > if (it->current_x < it->first_visible_x + x_incr) Ah! I have misunderstood what exactly expose_area is doing. The first visible glyph is a tab character, width ~64 pixels, which is only partially visible. It should start 42 pixels to the left of the window. expose_area calls draw_glyphs with an x coordinate of 0, which draws the entire tab instead of only the visible portion. It’s pretty simple to manually step through the two sides of the big if in expose_area and show that with the same input (except for row->fill_line_p) they will start drawing the line at different x coordinates. A minimal, and possibly correct, fix is: modified src/xdisp.c @@ -33491,7 +33491,7 @@ expose_area (struct window *w, struct glyph_row *row, const Emacs_Rectangle *r, if (area == TEXT_AREA && row->fill_line_p) /* If row extends face to end of line write the whole line. */ - draw_glyphs (w, 0, row, area, + draw_glyphs (w, row->x, row, area, 0, row->used[area], DRAW_NORMAL_TEXT, 0); else > So if in your case you get a glyph row with all the characters, > including those which are scrolled out of the viewport, then something > is wrong where the glyph row is prepared, not where it is displayed. > Specifically, when the window is hscrolled, display_line is called > again to produce the glyphs starting from the first visible glyph. > Perhaps in this case the NS display machinery uses a stale glyph row, > from before the hscrolling? I’m 100% sure the NS code is being passed bad coordinates. This isn’t just a problem when scrolling to the end of the line. If the window is horizontally scrolled and you move the cursor onto another line, the line that was previously wrong corrects itself and the line with the pointer on it now draws wrong. So it’s possible to move the pointer between two lines and have them jump left and right. Also the incorrectly drawn line doesn’t necessarily match any previously displayed line. If we had some cached glyph row I wouldn’t expect that to happen. -- Alan Third