From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.devel Subject: Re: Adding fake cursors when resizing a window. Date: Thu, 07 Mar 2019 17:39:20 -0800 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="145461"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Martin Rudalics , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 08 02:55:44 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h24jf-000bdr-6U for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2019 02:55:43 +0100 Original-Received: from localhost ([127.0.0.1]:35015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h24je-0003Tj-1I for ged-emacs-devel@m.gmane.org; Thu, 07 Mar 2019 20:55:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h24U0-00080C-RI for emacs-devel@gnu.org; Thu, 07 Mar 2019 20:39:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h24Tw-0007pe-J0 for emacs-devel@gnu.org; Thu, 07 Mar 2019 20:39:30 -0500 Original-Received: from gateway31.websitewelcome.com ([192.185.143.46]:47663) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h24Ts-0007ka-NZ for emacs-devel@gnu.org; Thu, 07 Mar 2019 20:39:25 -0500 Original-Received: from cm11.websitewelcome.com (cm11.websitewelcome.com [100.42.49.5]) by gateway31.websitewelcome.com (Postfix) with ESMTP id EBDF96E418 for ; Thu, 7 Mar 2019 19:39:21 -0600 (CST) Original-Received: from gator3053.hostgator.com ([50.87.144.69]) by cmsmtp with SMTP id 24TphJAowdnCe24TphDsml; Thu, 07 Mar 2019 19:39:21 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lawlist.com ; s=default; h=Content-Type:MIME-Version:Subject:Cc:To:From:Message-ID:Date: Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GCkkZJMgJctPMT2qFaXk7OvsGMXub9xBF935uYEHNWc=; b=FI8AmeqR92KXhffoSqYqxT5v9S k0y0v3djJdURINNU2vWz4Kiz3lWsvu4v2XlJZzf19OiTZH+Ah/+rewWIoc0q5w78iGD2rovROFkpp HQOsGcu3FeVI5amaUVrhTNeLsQ5JVIWMtLaG3Ws6WQ+Sv5p4U99WkqDkxUJA/FORhXjkrTZgnqtWH 6TKs6uUdm8LrOh2ro4+LbmqsM6bwOlMpkAyTqHZzm4XZSPn1NoZL+2noP4CidGJxRpeqgXyVZEvNU Q/cao7oeH4eF4baZUsRsF7enhkOLkvuchjupTUPZ5v8mzCfWWIUIpwFvNSIrURaOAQ+uoRfuIfG8m uMK/+7FQ==; Original-Received: from cpe-45-48-239-195.socal.res.rr.com ([45.48.239.195]:57420 helo=server.local) by gator3053.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.91) (envelope-from ) id 1h24Tp-003nAm-4e; Thu, 07 Mar 2019 19:39:21 -0600 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3053.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lawlist.com X-BWhitelist: no X-Source-IP: 45.48.239.195 X-Source-L: No X-Exim-ID: 1h24Tp-003nAm-4e X-Source-Sender: cpe-45-48-239-195.socal.res.rr.com (server.local) [45.48.239.195]:57420 X-Source-Auth: lawlist X-Email-Count: 2 X-Source-Cap: bGF3bGlzdDtsYXdsaXN0O2dhdG9yMzA1My5ob3N0Z2F0b3IuY29t X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 192.185.143.46 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:233902 Archived-At: Thank you, Eli and Martin, for reviewing and responding to this particular thread. I am able to observe the behavior described on Emacs for w32 and NS, but _not_ running on X11 with the current build settings. I have set up stderr messages in all locations where draw_glyphs is called and have concluded that draw_glyphs is _not_ responsible for erasing the fake cursors along the vertical strip that forms the scroll bar in the middle of the screen (which gets removed when the right window is deleted, and the left window increases to fill the entire frame). In addition to the stderr messages, I can visually see that the gap left in the area of fake cursors is the same width as the vertical scroll bar, and the gap does not align exactly with two characters. In other words, if draw_glyphs were somehow responsible for erasing the fake cursors in the area affected, then the fake cursors would be removed at the same X-axis and exact pixel width of each new character that gets drawn on the glass. I do not know why draw_glyphs is able to redraw the row without any problems, but drawing fake cursors along that region of the vertical scroll bar fails. On the w32 platform, the fake cursors at issue (BAR/HBAR_CURSOR) are drawn with w32_fill_area. On the NS platform, the fake cursors (BAR/HBAR_CURSOR) are drawn with NSRectFill. It probably would not be too difficult to create a minimal working example that draws/erases a horizontal line (the width of the window) every command loop to help demonstrate the issue, if that would be helpful .... ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > Date: [03-07-2019 07:12:57] <07 Mar 2019 17:12:57 +0200> > From: Eli Zaretskii > To: Keith David Bershatsky > CC: emacs-devel@gnu.org > Subject: Re: Adding fake cursors when resizing a window. > > > Date: Wed, 06 Mar 2019 19:42:16 -0800 > > From: Keith David Bershatsky > > > > Fact Pattern: Two-window left/right split with vertical scroll bars on each window. The user deletes the right window and the left window increases in size to fill the entire frame. update_window is called and all of the fake get erased at the outset using the window's current_matrix before scrolling_window is called. Then, draw_glyphs does its thing on the relevant lines and fake cursors are laid on each relevant line subsequent thereto. > > > > From what I can tell, it appears that draw_glyphs is able to write glyphs _underneath_ the vertical scroll bar in the center of the screen (that is about to be removed). However, drawing a rectangle (to create a fake cursor) from nsterm.m cannot write a fake cursor _underneath_ the vertical scroll bar in the center of the screen (that is about to be removed). When the vertical scroll bar is removed from the center of the screen, the area where the fake cursor could not be drawn is readily apparent. > > I'm confused by your description of the sequence of events. Is this > what happens on NS, or are you saying you see this on X and w32 as > well? I'm less familiar with the redisplay sequence on NS (and it > also recently tends to change frequently), but on X and w32 your > description is either inaccurate or misses something, because the > sequence AFAIK is like this: > > . redisplay_internal calls the condemn_scroll_bars_hook, which marks > all scroll bars as candidates for deletion > . then redisplay_internal calls redisplay_windows, which walks the > window-tree and examines each window, whereby each window that is > still alive in the window-tree "redeems" its scroll bars by > marking them not to be deleted > . then redisplay_internal calls judge_scroll_bars_hook, which > removes all the scroll bars that were not "redeemed" > . and only after that redisplay_internal calls update_frame, which > calls update_window for each live window, and that ends up calling > draw_glyphs to deliver the updated contents to the glass. > > So I don't understand why you see draw_glyphs draw "underneath" the > scroll bar, since by the time draw_glyphs is called, the scroll bar in > the middle of the frame was supposed to be deleted already. > > > One of my thoughts on dealing with this issue is to remove the vertical scroll bar (splitting the 2 windows) before update_window runs. > > AFAIK, we already do that, at least on X and on w32.