From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: [hober0@gmail.com: Re: mode-line redisplay bug] Date: Sat, 08 Oct 2005 22:26:59 +0100 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: sea.gmane.org 1128806983 9774 80.91.229.2 (8 Oct 2005 21:29:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 8 Oct 2005 21:29:43 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 08 23:29:40 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EOMFH-0006oX-8K for ged-emacs-devel@m.gmane.org; Sat, 08 Oct 2005 23:28:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EOMFG-0003UL-Gc for ged-emacs-devel@m.gmane.org; Sat, 08 Oct 2005 17:28:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EOMF4-0003UC-4F for emacs-devel@gnu.org; Sat, 08 Oct 2005 17:28:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EOMF3-0003Tv-AX for emacs-devel@gnu.org; Sat, 08 Oct 2005 17:28:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EOMF3-0003To-3Q for emacs-devel@gnu.org; Sat, 08 Oct 2005 17:28:29 -0400 Original-Received: from [194.106.33.237] (helo=outmail.freedom2surf.net) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EOMF2-0007Bf-0G; Sat, 08 Oct 2005 17:28:28 -0400 Original-Received: from wanchan.jasonrumney.net (i-83-67-23-108.freedom2surf.net [83.67.23.108]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id j98LSQch004220; Sat, 8 Oct 2005 22:28:26 +0100 Original-Received: from TONKOTSU-RAMEN (tonkotsu-ramen.jasonrumney.net [10.0.0.28]) by wanchan.jasonrumney.net (Postfix) with ESMTP id A9E21423; Sat, 8 Oct 2005 22:28:25 +0100 (BST) Original-To: rms@gnu.org In-Reply-To: (Jason Rumney's message of "Fri, 12 Aug 2005 23:56:41 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (windows-nt) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:43703 Archived-At: --=-=-= Jason Rumney writes: > On GNU/Linux: > > The highlit area flickers. On W32 it flickers once when the tooltip > pops up, but on X, it flickers constantly. I remember fixing something > like this on W32 years ago, it was in the code that detected mouse > movement - movement events were being sent for zero movement when > inside track-mouse forms. But my recollection is that the same bug did > not appear on X at the time, so even though the code appeared to be > the same, I did not try to apply my fix to the X code. I have looked at this and narrowed down the changes I made to w32term.c. Looking at the code again, I am sure that my changes should be applied to xterm.c as well, but applying them does not seem to make any difference to the flickering. It probably needs an X expert to look at it as I may have some misunderstanding here. In note_mouse_movement, which is called from handle_one_xevent in response to several types of event, we check the event's mouse position against last_mouse_glyph, to limit the number of events we pass through to lisp. last_mouse_glyph is updated in XTmouse_position, nowhere else as far as I can tell. XTmouse_position is installed as mouse_position_hook. As far as I can tell, it is called only when do_mouse_tracking is non-nil (in keyboard.c), or when the functions mouse-position and mouse-pixel-position (both in frame.c) are explicitly called. This means that last_mouse_glyph normally won't get updated, so it doesn't serve the purpose that we use it for. I fixed this in w32term.c by factoring out the code that updates last_mouse_glyph from w32_mouse_position (the equivalent of XTmouse_position) into a new function remember_mouse_glyph, and call it from note_mouse_movement when we notice the glyph has changed, to ensure it is always up to date. Having done that, I also noticed the following code from XTmouse_position: /* Arrange for the division in FRAME_PIXEL_X_TO_COL etc. to round down even for negative values. */ if (gx < 0) gx -= width - 1; if (gy < 0) gy -= height - 1; gx = (gx + width - 1) / width * width; gy = (gy + height - 1) / height * height; last_mouse_glyph.width = width; last_mouse_glyph.height = height; last_mouse_glyph.x = gx; last_mouse_glyph.y = gy; gx and gy are initially the position of the mouse. We are trying to find the rectangle around the glyph under the mouse here. On Windows, I found that this code returns the rectangle of a glyph diagonally adjacent to the glyph we want. I am not sure if I am missing something about the way X co-ordinates work, but I think the two lines that round gx and gy should be simply: gx = gx / width * width; gy = gy / height * height; Here is the full patch adapted to xterm.c. As I said, it does not seem to have any effect, so it needs someone more familiar with X to look at it further: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=xterm.patch 3584a3585,3586 > static void remember_mouse_glyph P_ ((struct frame *, int, int)); > 3609a3612,3613 > /* Remember which glyph we're now on. */ > remember_mouse_glyph (frame, event->x, event->y); 3679a3684,3724 > /* Remember which glyph the mouse is over. > */ > static void > remember_mouse_glyph (f1, win_x, win_y) > FRAME_PTR f1; > int win_x, win_y; > { > int width, height, gx, gy; > > /* Try getting the rectangle of the actual glyph. */ > if (!glyph_rect (f1, win_x, win_y, &last_mouse_glyph)) > { > /* If there is no glyph under the mouse, then we divide the screen > into a grid of the smallest glyph in the frame, and use that > as our "glyph". */ > width = FRAME_SMALLEST_CHAR_WIDTH (f1); > height = FRAME_SMALLEST_FONT_HEIGHT (f1); > gx = win_x; > gy = win_y; > > /* Arrange for the division in FRAME_PIXEL_X_TO_COL etc. to > round down even for negative values. */ > if (gx < 0) > gx -= width - 1; > if (gy < 0) > gy -= height - 1; > #if 0 > gx = (gx + width - 1) / width * width; > gy = (gy + height - 1) / height * height; > #else > gx = gx / width * width; > gy = gy / width * width; > #endif > last_mouse_glyph.width = width; > last_mouse_glyph.height = height; > last_mouse_glyph.x = gx; > last_mouse_glyph.y = gy; > } > } > > 3866,3891c3911 < int width, height, gx, gy; < XRectangle rect; < < if (glyph_rect (f1, win_x, win_y, &rect)) < last_mouse_glyph = rect; < else < { < width = FRAME_SMALLEST_CHAR_WIDTH (f1); < height = FRAME_SMALLEST_FONT_HEIGHT (f1); < gx = win_x; < gy = win_y; < < /* Arrange for the division in FRAME_PIXEL_X_TO_COL etc. to < round down even for negative values. */ < if (gx < 0) < gx -= width - 1; < if (gy < 0) < gy -= height - 1; < gx = (gx + width - 1) / width * width; < gy = (gy + height - 1) / height * height; < < last_mouse_glyph.width = width; < last_mouse_glyph.height = height; < last_mouse_glyph.x = gx; < last_mouse_glyph.y = gy; < } --- > remember_mouse_glyph (f1, win_x, win_y); --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --=-=-=--