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: Sun, 4 Nov 2018 13:24:04 +0000 Message-ID: <20181104132404.GA58336@breton.holly.idiocy.org> References: <83tvl0hdn6.fsf@gnu.org> <20181101225519.GA40584@breton.holly.idiocy.org> <837ehufqxw.fsf@gnu.org> <20181103203635.GB41015@breton.holly.idiocy.org> <83muqpeuw0.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 1541337794 23224 195.159.176.226 (4 Nov 2018 13:23:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Nov 2018 13:23:14 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: boris@d12frosted.io, 32932@debbugs.gnu.org, aaronjensen@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 04 14:23:09 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 1gJIMu-0005uU-Dk for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Nov 2018 14:23:08 +0100 Original-Received: from localhost ([::1]:59037 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJIP0-000757-OR for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Nov 2018 08:25:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35898) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJIOp-00072K-VS for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 08:25:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJIOk-0002NW-WC for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 08:25:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57423) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJIOk-0002N7-Qc for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 08:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gJIOk-00061a-Hv for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 08:25: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: Sun, 04 Nov 2018 13:25: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.154133785623092 (code B ref 32932); Sun, 04 Nov 2018 13:25:02 +0000 Original-Received: (at 32932) by debbugs.gnu.org; 4 Nov 2018 13:24:16 +0000 Original-Received: from localhost ([127.0.0.1]:33448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJINz-00060N-B1 for submit@debbugs.gnu.org; Sun, 04 Nov 2018 08:24:15 -0500 Original-Received: from mail-wr1-f45.google.com ([209.85.221.45]:39582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJINx-00060B-Nw for 32932@debbugs.gnu.org; Sun, 04 Nov 2018 08:24:14 -0500 Original-Received: by mail-wr1-f45.google.com with SMTP id r10-v6so6541860wrv.6 for <32932@debbugs.gnu.org>; Sun, 04 Nov 2018 05:24:13 -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 :user-agent; bh=t0bni31L1MviojnS4c3imsUbu7Hyw6VPA4qf/rJXP8M=; b=ilnfT7y9dRFGZ5MhYhbd/QuBy7GMpGhGLiCxIga69cc/QuMQb35pvGOdulL/fJ3peX Hzvr/Q+Et6MxzYVIURlWOvogGeEMbiaO9IurgSofacgjIfjbxH0oqXJvzlRceL6qaX4a kjEQZsltEvQ9DU7AQK1EZWY2s9Qo6EsGBDun5gArK8ka4Ja9PydzNNjYTDT58qe3eIky zVrWsFrihjNgFEoFhRfHBDPeX9eBfg+NUjioEVhvrv2LLIkRK0gkyFeLtB8QfPr9XtJD OCa6QhfPapv+aH54JRpjvyj5odexaHZbaV9ChP+nV/Z9QS0Ydz9y98XGKRM4e+Ifwg0W ba9g== 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=t0bni31L1MviojnS4c3imsUbu7Hyw6VPA4qf/rJXP8M=; b=evmfnziPwGELcVdMR5/oaDf9L5h/Qo855rpxKZLoe/3hu1VDsh6ERfIDszxa2QsSiJ nylVlqEZzbn5nMsx623uIuGawdu6o2Le8ViHZdoj74H7pbe/3H/IZ6TOm+vU4lsNRf5b JoWlghtDzys93ojZBWNrZ2zbEJDI2AfMLHG5bLDBHaWK+NHFGdTXyFS+NiNtmakpwhEL 658RdKqZSxkT9flJ/kNoCiNE+N4jLWaL2eeM/SwBrIPvBT49/lq+5zWVDe7uM65j7EI6 zvJVGHpFJnOo04JKdjxqjdHixzaPtInYlwCS200i+fFc+vArZllwZrksirqtfSZt4wYT 53UQ== X-Gm-Message-State: AGRZ1gKYjhOE96l99ymzmcrYKhWyuMpbbG7finUqmnRT9oSO2HOPwelI Qui3SJQzbAVRb0MajzYAhGA= X-Google-Smtp-Source: AJdET5f4vvz+qZfx2iXzTzqbs93mIgTtfXOPivETUNffBtEmzQQwWB3Rndb71KSCXk9u3YbF1ZX5sQ== X-Received: by 2002:a5d:6b4f:: with SMTP id x15-v6mr15832889wrw.304.1541337847761; Sun, 04 Nov 2018 05:24:07 -0800 (PST) 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 r1sm18933486wrx.15.2018.11.04.05.24.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 05:24:06 -0800 (PST) Content-Disposition: inline In-Reply-To: <83muqpeuw0.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:152012 Archived-At: On Sat, Nov 03, 2018 at 11:03:27PM +0200, Eli Zaretskii wrote: > > Or perhaps expose_frame actually thinks it should be blank at that > > moment, but for some reason we’ve not marked the whole window or > > whatever as dirty? > > > > So we’re to display an image but it’s not loaded yet, so redisplay > > blanks the window for the time being, but we fail to mark it dirty or > > garbaged. Expose_frame comes along and draws the bit we’ve previously > > asked it to draw. Finally the image loads and redisplay marks the > > whole window as dirty leading to everything catching up at the next > > expose_frame. > > I'm puzzled by this description, and actually by the whole larger > picture. You see, I originally thought you had a problem of > flickering caused by redrawing the cursor, which was said to trigger > redrawing of the entire screen line where the cursor was, instead of > redrawing just the character under the cursor. Is that still the > problem we are discussing? If so, how does visiting the image file > come into play, and where is cursor positioned in this scenario? Apologies, Aaron’s repeatable test case involves a dired buffer of images and hitting return on one of the images. There’s a pause while it loads, during which the line with the cursor on it sometimes blanks. Then the image loads. I think what’s probably happening is that when the image begins to load the emacs window containing the dired buffer is marked as garbaged as it’s going to be replaced by the buffer containing the image, however because there’s a reasonably long gap between the user requesting the opening of the image, and the image actually loading redisplay and expose_frame have time to run. Because the window is marked as garbaged expose_window doesn’t do anything. This would be fine except we seem to have a rogue clear_area somewhere. NSTrace doesn’t show it running, and they happen too often for me to reasonably use a breakpoint to find it. Here’s some output from NSTrace: nsterm.m : 4441: [53008] ns_select nsterm.m : 5391: [53009] | [EmacsApp run] nsterm.m : 5458: [53010] | | [EmacsApp sendEvent:] nsterm.m : 5459: [53011] | | +--- Type: 10 Here we have the user hitting return in the image file in dired. nsterm.m : 6076: [53012] | | | [EmacsView keyDown:] nsterm.m : 4195: [53013] | | | | ns_send_appdefined(-1) nsterm.m : 5458: [53014] | | [EmacsApp sendEvent:] nsterm.m : 5459: [53015] | | +--- Type: 15 nsterm.m : 5429: [53016] | | | [EmacsApp stop:] nsterm.m : 4359: [53017] | ns_read_socket nsterm.m : 4359: [53018] | ns_read_socket nsterm.m : 4195: [53019] | | ns_send_appdefined(-1) nsterm.m : 5391: [53020] | | [EmacsApp run] nsterm.m : 5458: [53021] | | | [EmacsApp sendEvent:] nsterm.m : 5459: [53022] | | | +--- Type: 15 nsterm.m : 5429: [53023] | | | | [EmacsApp stop:] nsterm.m : 4359: [53024] | ns_read_socket nsterm.m : 4195: [53025] | | ns_send_appdefined(-1) nsterm.m : 5391: [53026] | | [EmacsApp run] nsterm.m : 5458: [53027] | | | [EmacsApp sendEvent:] nsterm.m : 5459: [53028] | | | +--- Type: 15 nsterm.m : 5429: [53029] | | | | [EmacsApp stop:] nsterm.m : 4359: [53030] ns_read_socket nsterm.m : 4195: [53031] | ns_send_appdefined(-1) nsterm.m : 5391: [53032] | [EmacsApp run] nsterm.m : 5458: [53033] | | [EmacsApp sendEvent:] nsterm.m : 5459: [53034] | | +--- Type: 15 nsterm.m : 5429: [53035] | | | [EmacsApp stop:] I believe this is now Emacs trying to modify the cursor. The cursor is at pixel position (381, 268). nsterm.m : 2299: [53036] ns_lisp_to_color nsterm.m : 2177: [53037] | ns_get_color(LightGoldenrod3, **) nsterm.m : 4035: [53038] ns_draw_glyph_string nsterm.m : 1191: [53039] | ns_clip_to_rect ns_clip_to_rect nsterm.m : 1195: [53040] | +--- r: (X:10 Y:268)/(W:560 H:14) nsterm.m : 1214: [53041] | +--- New dirty rect: (X:10 Y:268)/(W:560 H:14) nsterm.m : 3048: [53042] ns_draw_window_cursor nsterm.m : 3048: [53043] ns_draw_window_cursor nsterm.m : 3048: [53044] ns_draw_window_cursor nsterm.m : 1191: [53045] | ns_clip_to_rect ns_clip_to_rect nsterm.m : 1195: [53046] | +--- r: (X:381 Y:268)/(W:7 H:14) nsterm.m : 1214: [53047] | +--- New dirty rect: (X:381 Y:268)/(W:7 H:14) nsterm.m : 3048: [53048] ns_draw_window_cursor nsimage.m : 61: [53049] ns_image_for_XPM I think these are functions called by redisplay_internal. I believe they’re updating the modeline and/or the minibuffer. nsterm.m : 1060: [53050] ns_update_begin nsterm.m : 1015: [53051] | ns_update_auto_hide_menu_bar nsterm.m : 7772: [53052] | [EmacsView isFullscreen] ->> 0 nsterm.m : 1109: [53053] ns_update_window_begin nsterm.m : 4035: [53054] ns_draw_glyph_string nsterm.m : 1191: [53055] | ns_clip_to_rect ns_clip_to_rect nsterm.m : 1195: [53056] | +--- r: (X:10 Y:492)/(W:560 H:14) nsterm.m : 1214: [53057] | +--- New dirty rect: (X:10 Y:492)/(W:560 H:14) nsterm.m : 2682: [53058] ns_clear_frame_area nsterm.m : 1191: [53059] | ns_clip_to_rect ns_clip_to_rect nsterm.m : 1195: [53060] | +--- r: (X:416 Y:492)/(W:154 H:14) nsterm.m : 1214: [53061] | +--- New dirty rect: (X:416 Y:492)/(W:154 H:14) nsterm.m : 1139: [53062] ns_update_window_end nsterm.m : 3048: [53063] | ns_draw_window_cursor nsterm.m : 1176: [53064] ns_update_end nsterm.m : 2532: [53065] ns_frame_up_to_date nsterm.m : 4359: [53066] ns_read_socket nsterm.m : 4195: [53067] | ns_send_appdefined(-1) nsterm.m : 5391: [53068] | [EmacsApp run] Now drawRect is called. It currently steps through each of the unique dirty rectangles calling expose_frame. nsterm.m : 8100: [53069] | | [EmacsView drawRect:(X:10 Y:268)/(W:560 H:238)] modeline/minibuffer: nsterm.m : 8117: [53070] | | +--- Exposing rect: (X:10 Y:492)/(W:560 H:14) nsterm.m : 3048: [53071] | | | ns_draw_window_cursor nsterm.m : 4035: [53072] | | | ns_draw_glyph_string nsterm.m : 1191: [53073] | | | | ns_clip_to_rect ns_clip_to_rect nsterm.m : 1195: [53074] | | | | +--- r: (X:10 Y:492)/(W:560 H:14) nsterm.m : 3624: [53075] | | | | ns_maybe_dumpglyphs_background nsterm.m : 1229: [53076] | | | | ns_reset_clipping nsterm.m : 2922: [53077] | | | ns_draw_fringe_bitmap nsterm.m : 2924: [53078] | | | +--- which:0 cursor:0 overlay:0 width:0 height:0 period:0 nsterm.m : 1191: [53079] | | | | ns_clip_to_rect ns_clip_to_rect nsterm.m : 1195: [53080] | | | | +--- r: (X:2 Y:492)/(W:8 H:14) nsterm.m : 2961: [53081] | | | +--- clearRect: (X:2 Y:492)/(W:8 H:14) nsterm.m : 1229: [53082] | | | | ns_reset_clipping nsterm.m : 2922: [53083] | | | ns_draw_fringe_bitmap nsterm.m : 2924: [53084] | | | +--- which:0 cursor:0 overlay:0 width:0 height:0 period:0 nsterm.m : 1191: [53085] | | | | ns_clip_to_rect ns_clip_to_rect nsterm.m : 1195: [53086] | | | | +--- r: (X:570 Y:492)/(W:8 H:14) nsterm.m : 2961: [53087] | | | +--- clearRect: (X:570 Y:492)/(W:8 H:14) nsterm.m : 1229: [53088] | | | | ns_reset_clipping nsterm.m : 3048: [53089] | | | ns_draw_window_cursor Here it finally reaches the rectangle that contains the cursor. It appears to do nothing. Not even clear the area. nsterm.m : 8117: [53090] | | +--- Exposing rect: (X:10 Y:268)/(W:560 H:14) nsterm.m : 5458: [53091] | | [EmacsApp sendEvent:] nsterm.m : 5459: [53092] | | +--- Type: 11 I’ve tried to work out if drawRect is ‘helpfully’ clearing the dirty rectangles for us, but I don’t think it is. Perhaps this approach is just doomed to suffer from issues like these. -- Alan Third