From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#32932: 27.0.50; render bugs on macOS Mojave Date: Sat, 03 Nov 2018 23:03:27 +0200 Message-ID: <83muqpeuw0.fsf@gnu.org> References: <20181031171253.GA69712@breton.holly.idiocy.org> <83tvl0hdn6.fsf@gnu.org> <20181101225519.GA40584@breton.holly.idiocy.org> <837ehufqxw.fsf@gnu.org> <20181103203635.GB41015@breton.holly.idiocy.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 1541278925 22674 195.159.176.226 (3 Nov 2018 21:02:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Nov 2018 21:02:05 +0000 (UTC) Cc: boris@d12frosted.io, 32932@debbugs.gnu.org, aaronjensen@gmail.com To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 03 22:02:01 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 1gJ33P-0005kK-Vu for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Nov 2018 22:02:00 +0100 Original-Received: from localhost ([::1]:56773 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJ35W-0001xl-8I for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Nov 2018 17:04:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJ35Q-0001t2-8h for bug-gnu-emacs@gnu.org; Sat, 03 Nov 2018 17:04:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJ35O-0000MH-VO for bug-gnu-emacs@gnu.org; Sat, 03 Nov 2018 17:04:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57161) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJ35O-0000HP-5H for bug-gnu-emacs@gnu.org; Sat, 03 Nov 2018 17:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gJ35N-000090-TU for bug-gnu-emacs@gnu.org; Sat, 03 Nov 2018 17:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Nov 2018 21:04:01 +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.1541279035540 (code B ref 32932); Sat, 03 Nov 2018 21:04:01 +0000 Original-Received: (at 32932) by debbugs.gnu.org; 3 Nov 2018 21:03:55 +0000 Original-Received: from localhost ([127.0.0.1]:33186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJ35H-00008e-0I for submit@debbugs.gnu.org; Sat, 03 Nov 2018 17:03:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJ35E-00008M-4O for 32932@debbugs.gnu.org; Sat, 03 Nov 2018 17:03:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJ354-00083e-EI for 32932@debbugs.gnu.org; Sat, 03 Nov 2018 17:03:46 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJ34y-0007zL-OA; Sat, 03 Nov 2018 17:03:39 -0400 Original-Received: from [176.228.60.248] (port=4756 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gJ34x-00030S-3O; Sat, 03 Nov 2018 17:03:36 -0400 In-reply-to: <20181103203635.GB41015@breton.holly.idiocy.org> (message from Alan Third on Sat, 3 Nov 2018 20:36:35 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:151990 Archived-At: > Date: Sat, 3 Nov 2018 20:36:35 +0000 > From: Alan Third > Cc: aaronjensen@gmail.com, boris@d12frosted.io, 32932@debbugs.gnu.org > > > I think if you are basing the redisplay on marking portions dirty, you > > need to include the same logic as in display_and_set_cursor and its > > callers. > > What I don’t understand is how we’re getting a blanking of the line. > When redisplay runs it’s incapable of drawing to the screen, and even > if we mark too large an area as dirty it won’t draw anything at that > point. What do you mean by "redisplay" in this context? The function redisplay_internal and the subroutines it calls? If so, yes, that doesn't draw anything, because AFAIU you've modified the functions called from update_frame to mark portions of the frame dirty, but not to redraw them. (Other platforms do the redrawing inside update_frame and update_window.) > Later drawRect runs which calls expose_frame on the area we’ve marked > as dirty. NOW it can draw to the screen, but for it to leave a line > blank it would have to actually call clear_frame or clear_frame_area, > then not call anything to draw over the blanked area. > > Is it possible for expose_frame to stop drawing part‐way through? No, I don't think so. But what actually draws when expose_frame is called is the backend-specific draw_glyph_string method, see draw_glyphs. What does the NS implementation of that method do when it is handed a glyph string to draw? does it blank the entire line or a part of it first? > 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?