From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#32932: 27.0.50; render bugs on macOS Mojave Date: Thu, 1 Nov 2018 22:55:19 +0000 Message-ID: <20181101225519.GA40584@breton.holly.idiocy.org> References: <20181029160943.GA60662@breton.holly.idiocy.org> <20181031171253.GA69712@breton.holly.idiocy.org> <83tvl0hdn6.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1541112938 7447 195.159.176.226 (1 Nov 2018 22:55:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Nov 2018 22:55:38 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: boris@d12frosted.io, 32932@debbugs.gnu.org, Aaron Jensen To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 01 23:55:34 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1gILsD-0001rL-JG for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Nov 2018 23:55:33 +0100 Original-Received: from localhost ([::1]:47014 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gILuK-0004Vz-1e for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Nov 2018 18:57:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gILsk-0003O0-I5 for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 18:56:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gILsh-0002fi-8k for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 18:56:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54783) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gILsg-0002fQ-UQ for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 18:56:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gILsg-0006ns-7x for bug-gnu-emacs@gnu.org; Thu, 01 Nov 2018 18:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Nov 2018 22:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32932 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32932-submit@debbugs.gnu.org id=B32932.154111293126109 (code B ref 32932); Thu, 01 Nov 2018 22:56:02 +0000 Original-Received: (at 32932) by debbugs.gnu.org; 1 Nov 2018 22:55:31 +0000 Original-Received: from localhost ([127.0.0.1]:59041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gILsA-0006n3-PS for submit@debbugs.gnu.org; Thu, 01 Nov 2018 18:55:31 -0400 Original-Received: from mail-wm1-f46.google.com ([209.85.128.46]:37941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gILs8-0006mq-NV for 32932@debbugs.gnu.org; Thu, 01 Nov 2018 18:55:29 -0400 Original-Received: by mail-wm1-f46.google.com with SMTP id l2-v6so405489wmh.3 for <32932@debbugs.gnu.org>; Thu, 01 Nov 2018 15:55:28 -0700 (PDT) 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 :user-agent; bh=cU4yjYOw2E9udt9qEJFhKmK+LjoAd7QRLnuBMGejV8w=; b=qhFxFw4DmvHQZQw3qre4taAM3L3EnFeJGFaVvOWoBSz/STCYamQR3nsagLeqUnrjMO aL8/3GXhO70KLUJEtb6NYujiUr2cjxezQ0hNcNt6WL4I/2w5NQkxwIQEA5ozUyWHiLXh oL5l/bf3567UpVeZV97r2D3uZjKns9i9YoEYxQqgBxaA8Kdi9UcVsH/5cX4DT8mvg1xD IvMwkzynT6EqXXQ0SS2asU2UaOES4Ry/5hVJtVJ7Yzh88qa93QAWRYXrUR7McHtHC0/h csw8zHaiHfeYxPjg1PHp2NICvpGD07LdFnWKjEavuACZoelWYjBeqymlEpV7zHAce/8S EdEA== 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:user-agent; bh=cU4yjYOw2E9udt9qEJFhKmK+LjoAd7QRLnuBMGejV8w=; b=K9XCkcdc9mGYJe8lmjX6ElvNxpoYNoAkExITGrZAJJnQ1PX3xNv1SGH2mubveixO54 RvTiX7y1AjfjclSB2icTgsEgfvjnlkyUqX0FQyZ0C3yy6EHQ1Ikj599YVIJ7lOPAfptU hr+2UJyly9/8kdA0CKCJUGWzbFQT6JnZCTcewdO/dYGhmaE3Joq3b88jDebEPG12THcu 5ZX7zI/D0GNxWjOHOZ7DwCyAUlHtgn+AlE4eCAlFVQda256QWTawfYLNfCFHoyXubtsw ranwBMDlTWsSDIYJtEZ3aK8DvTde2D0sYWdtzxAN/xgC6UWqRP0aStjSzx/QkEUbxFhJ +YZA== X-Gm-Message-State: AGRZ1gIUJCsrEMv2eEG7zjQl521m4oNkJaKNEAgDtKzDo3iRDmg41tkX 5YJCE7MGNGfWCs0xqWvPfSc= X-Google-Smtp-Source: AJdET5cRE87MQSl2RW31GMjA60+1Vko+3zNtrN1bmQUImbABkyLMVns0e+R+H4Zqu1Y5GFX2/pnaGQ== X-Received: by 2002:a1c:96c7:: with SMTP id y190-v6mr7126015wmd.36.1541112922712; Thu, 01 Nov 2018 15:55:22 -0700 (PDT) Original-Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-8cfe-35d9-62a3-d426.holly.idiocy.org. [2001:8b0:3f8:8129:8cfe:35d9:62a3:d426]) by smtp.gmail.com with ESMTPSA id e14-v6sm6338000wrv.93.2018.11.01.15.55.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Nov 2018 15:55:21 -0700 (PDT) Content-Disposition: inline In-Reply-To: <83tvl0hdn6.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: 208.118.235.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:151927 Archived-At: On Thu, Nov 01, 2018 at 08:10:53PM +0200, Eli Zaretskii wrote: > > From: Aaron Jensen > > Date: Wed, 31 Oct 2018 23:51:42 -0700 > > Cc: Alan Third , 32932@debbugs.gnu.org > > > > getting set causes erase_phys_cursor to get called, which ultimately > > calls draw_phys_cursor_glyph, which calls draw_glyphs, which I believe > > is what is blanking the line. It appears to be more than just > > redrawing the glyph under the cursor. > > > > Another clue is that it appear to only blank from where the cursor is > > to the end of the line. Anything before that isn’t cleared. > > Can you find the reason for that? In general, redrawing the cursor > should only redraw a single character, and sometimes the two adjacent > ones. It shouldn't redraw more than that. > > From what you describe, it sounds like the problem is in the logic > that determines which parts to redraw, see update_text_area in > dispnew.c. I’ve done some digging, and I’m pretty tired right now so apologies if this makes no sense, but it looks as though when Emacs is clearing the cursor it redraws the entire line that contains the cursor. This is something being done to a line with the cursor on it: New dirty rect:(X:10 Y:380)/(W:560 H:14) Process 40552 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x00000001003ae24a Emacs`ns_clip_to_rect(f=0x00000001030527b0, r=(origin = (x = 10, y = 380), size = (width = 560, height = 14)), n=1) at nsterm.m:1214 1211 { 1212 fprintf (stderr, "New dirty rect:" NSTRACE_FMT_RECT "\n", 1213 NSTRACE_ARG_RECT(r[i])); -> 1214 [view setNeedsDisplayInRect:r[i]]; 1215 } 1216 } 1217 } Target 0: (Emacs) stopped. I’m printing out the area that Emacs wants to draw (New dirty rect). It has a width of 560, which is, I think, the full width of the text area. The interesting bit of the backtrace: * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x00000001003ae24a Emacs`ns_clip_to_rect(f=0x00000001030527b0, r=(origin = (x = 10, y = 380), size = (width = 560, height = 14)), n=1) at nsterm.m:1214 frame #1: 0x00000001003e29bf Emacs`ns_draw_glyph_string(s=0x00007ffeefbfbf10) at nsterm.m:4096 frame #2: 0x000000010006f742 Emacs`draw_glyphs(w=0x0000000103051630, x=388, row=0x00000001030fb100, area=TEXT_AREA, start=53, end=54, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:26878 frame #3: 0x0000000100070c2e Emacs`draw_phys_cursor_glyph(w=0x0000000103051630, row=0x00000001030fb100, hl=DRAW_NORMAL_TEXT) at xdisp.c:29434 frame #4: 0x0000000100071369 Emacs`erase_phys_cursor(w=0x0000000103051630) at xdisp.c:29570 frame #5: 0x0000000100071884 Emacs`display_and_set_cursor(w=0x0000000103051630, on=true, hpos=53, vpos=27, x=371, y=378) at xdisp.c:29659 frame #6: 0x0000000100072243 Emacs`update_window_cursor(w=0x0000000103051630, on=true) at xdisp.c:29714 frame #7: 0x000000010007204d Emacs`update_cursor_in_window_tree(w=0x0000000103051630, on_p=true) at xdisp.c:29732 frame #8: 0x0000000100071fd2 Emacs`x_update_cursor(f=0x00000001030527b0, on_p=true) at xdisp.c:29746 frame #9: 0x00000001003c3b0e Emacs`ns_frame_rehighlight(frame=0x00000001030527b0) at nsterm.m:1508 frame #10: 0x00000001003c3607 Emacs`-[EmacsView windowDidBecomeKey](self=0x00000001022a8b20, _cmd="windowDidBecomeKey") at nsterm.m:7159 frame #11: 0x00000001003c3428 Emacs`-[EmacsView windowDidBecomeKey:](self=0x00000001022a8b20, _cmd="windowDidBecomeKey:", notification=@"NSWindowDidBecomeKeyNotification") at nsterm.m:7145 You can see that ‘draw_glyphs’ is being called with start=53 and end=54, which sounds, to me, like it’s wanting to draw one glyph: the one under the cursor. However when it gets round to asking to clip to an area (ns_clip_to_rect) it’s wanting the entire row. The parameter s in ns_draw_glyph_string looks right to me (i.e. x, y, width and height look right for a single glyph): (lldb) p *s (glyph_string) $1 = { x = 381 y = 380 ybase = 391 width = 7 background_width = 7 height = 14 left_overhang = 0 right_overhang = 0 f = 0x00000001030527b0 w = 0x0000000103051630 display = 0x0000000000000000 row = 0x00000001030fb100 area = TEXT_AREA char2b = 0x00007ffeefbfbf00 u"'" nchars = 1 hl = DRAW_NORMAL_TEXT face = 0x000000010229e130 font = 0x000000010427c848 cmp = 0x0000000000000000 cmp_id = 0 cmp_from = 0 cmp_to = 0 extends_to_end_of_line_p = false background_filled_p = false font_not_found_p = false stippled_p = false for_overlaps = 0 padding_p = false first_glyph = 0x00000001030ed9f0 img = 0x0000000000000000 xwidget = 0x0000000000000000 slice = (x = 0, y = 0, width = 0, height = 0) clip_head = 0x0000000000000000 clip_tail = 0x0000000000000000 clip = ([0] = (origin = (x = 0, y = 0), size = (width = 0, height = 0)), [1] = (origin = (x = 0, y = 0), size = (width = 0, height = 0))) num_clips = 0 underline_position = 0 underline_thickness = 0 next = 0x0000000000000000 prev = 0x0000000000000000 } Here’s where it’s working out the clipping rectangle: (lldb) f 1 frame #1: 0x00000001003e29bf Emacs`ns_draw_glyph_string(s=0x00007ffeefbfbf10) at nsterm.m:4096 4093 case CHAR_GLYPH: 4094 case COMPOSITE_GLYPH: 4095 n = ns_get_glyph_string_clip_rect (s, r); -> 4096 if (ns_clip_to_rect (s->f, r, n)) 4097 { 4098 if (s->for_overlaps || (s->cmp_from > 0 4099 && ! s->first_glyph->u.cmp.automatic)) ns_get_glyph_string_clip_rect is a simple wrapper round get_glyph_string_clip_rects, so when asked for the clipping rectangle for a single glyph, it returns a rectangle covering the entire row. Because we just mark it as dirty and come back to draw it later we do end up redrawing the entire row. I don’t know if this is a bug in get_glyph_string_clip_rects, or if we’re misusing it here and should work out our own clipping rectangles. I still don’t know why this results in the row being blanked out, though. -- Alan Third