all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Antipov <dmantipov@yandex.ru>
To: "Jan Djärv" <jan.h.d@swipnet.se>
Cc: 15398@debbugs.gnu.org, Serge Kosyrev <skosyrev@ptsecurity.ru>,
	Samium Gromoff <_deepfire@feelingofgreen.ru>
Subject: bug#15398: 24.3; Frame redraw completely screwed
Date: Fri, 20 Sep 2013 12:00:46 +0400	[thread overview]
Message-ID: <523C00AE.1020108@yandex.ru> (raw)
In-Reply-To: <55618AAD-86FE-42A7-8179-D5F58C25171C@swipnet.se>

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On 09/20/2013 10:47 AM, Jan Djärv wrote:

> 20 sep 2013 kl. 05:41 skrev Dmitry Antipov <dmantipov@yandex.ru>:
>
>> On 09/19/2013 08:41 PM, Jan Djärv wrote:
>>
>>> I don't recall all the details, but I think the comment actually means "for GTK 2.6 and newer".
>>
>> Ugh. Reverted in r114402 (for visible frames; in general, I think
>> that it is possible to handle Expose events a bit more intelligently).
>
> Not as long as we do pure X-calls on Gtk-widgets.

Yes, mixing Xlib and Gtk is ugly. But I would like to get your comments on this first
(also I'm looking for brave testers).

Dmitry


[-- Attachment #2: gtk_clear_expose.patch --]
[-- Type: text/x-patch, Size: 2923 bytes --]

=== modified file 'src/frame.h'
--- src/frame.h	2013-09-17 12:59:45 +0000
+++ src/frame.h	2013-09-20 07:39:22 +0000
@@ -395,6 +395,12 @@
      selected window on this frame have frozen window starts.  */
   unsigned frozen_window_starts : 1;
 
+#ifdef USE_GTK
+  /* If menu or tooltip window disappeared, this is set to number
+     of Expose events we should handle with call to x_clear_area.  */
+  unsigned gtk_clear_expose;
+#endif
+
   /* Nonzero if we should actually display the scroll bars on this frame.  */
   enum vertical_scroll_bar_type vertical_scroll_bar_type;
 

=== modified file 'src/xterm.c'
--- src/xterm.c	2013-09-20 03:30:50 +0000
+++ src/xterm.c	2013-09-20 07:53:19 +0000
@@ -5788,6 +5788,33 @@
 
   return GDK_FILTER_CONTINUE;
 }
+
+/* Find the frame which has the same root X window as W.  */
+
+static struct frame *
+x_frame_root_match (struct x_display_info *dpyinfo, Window w)
+{
+  XWindowAttributes xww, xwf;
+
+  if (XGetWindowAttributes (dpyinfo->display, w, &xww))
+    {
+      Lisp_Object tail, frame;
+
+      FOR_EACH_FRAME (tail, frame)
+	{
+	  struct frame *f = XFRAME (frame);
+
+	  if (FRAME_X_P (f) && FRAME_X_OUTPUT (f)
+	      && FRAME_DISPLAY_INFO (f) == dpyinfo
+	      && XGetWindowAttributes (dpyinfo->display,
+		   FRAME_X_OUTPUT (f)->window_desc, &xwf))
+	    if (xww.root == xwf.root)
+	      return f;
+	}
+    }
+  return NULL;
+}
+
 #endif /* USE_GTK */
 
 
@@ -6111,12 +6138,23 @@
           else
 	    {
 #ifdef USE_GTK
-	      /* This seems to be needed for GTK 2.6 and later, see
-		 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15398.  */
-	      x_clear_area (event->xexpose.display,
-			    event->xexpose.window,
-			    event->xexpose.x, event->xexpose.y,
-			    event->xexpose.width, event->xexpose.height);
+	      /* This is an attempt to call x_clear_area only if needed,
+		 see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15398.  */
+
+	      if (f->gtk_clear_expose == 1)
+		/* Collection of Expose events was requested, do that.  */
+		f->gtk_clear_expose += event->xexpose.count;
+
+	      /* Next, handle all collected Expose events
+		 with an extra call to x_clear_area.  */
+	      if (f->gtk_clear_expose > 0)
+		{
+		  x_clear_area (event->xexpose.display,
+				event->xexpose.window,
+				event->xexpose.x, event->xexpose.y,
+				event->xexpose.width, event->xexpose.height);
+		  f->gtk_clear_expose--;
+		}
 #endif
 	      expose_frame (f, event->xexpose.x, event->xexpose.y,
 			    event->xexpose.width, event->xexpose.height);
@@ -6205,6 +6243,16 @@
               XSETFRAME (inev.ie.frame_or_window, f);
             }
         }
+#ifdef USE_GTK
+      else
+	{
+	  f = x_frame_root_match (dpyinfo, event->xunmap.window);
+	  if (f)
+	    /* Menu or tooltip window on F has disappeared.
+	       Request collecting Expose events on this frame.  */
+	    f->gtk_clear_expose = 1;
+	}
+#endif
       goto OTHER;
 
     case MapNotify:


  reply	other threads:[~2013-09-20  8:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-16 19:48 bug#15398: 24.3; Frame redraw completely screwed Samium Gromoff
2013-09-16 20:53 ` Jan Djärv
2013-09-17  6:19   ` bug#15398: UNS: " Samium Gromoff
2013-09-17  7:23     ` Eli Zaretskii
2013-09-17 18:50       ` Jan Djärv
2013-09-17 21:17       ` bug#15398: UNS: " Samium Gromoff
2013-09-18  6:27         ` Eli Zaretskii
2013-09-18 21:07           ` Samium Gromoff
2013-09-19  6:50             ` Eli Zaretskii
2013-09-19  8:05               ` martin rudalics
2013-09-19  8:10                 ` Eli Zaretskii
2013-09-19  8:27                   ` martin rudalics
2013-09-19  8:53                     ` Eli Zaretskii
2013-09-19  9:25                       ` martin rudalics
2013-09-19  9:31                         ` Eli Zaretskii
2013-09-19 10:58                           ` martin rudalics
2013-09-19 13:04                             ` Eli Zaretskii
2013-09-19 14:03                               ` martin rudalics
2013-09-19 14:20                                 ` Eli Zaretskii
2013-09-19 14:24                                   ` martin rudalics
2013-09-19 16:17                                 ` Glenn Morris
2013-09-19 17:06                                   ` martin rudalics
2013-09-19 14:04                 ` Stefan Monnier
2013-09-19 14:21                   ` martin rudalics
2013-09-19 14:54                   ` Serge Kosyrev
2013-09-19 16:41                     ` Jan Djärv
2013-09-20  3:41                       ` Dmitry Antipov
2013-09-20  6:47                         ` Jan Djärv
2013-09-20  8:00                           ` Dmitry Antipov [this message]
2013-09-20  9:32                             ` Jan Djärv
2020-09-09 13:24                         ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=523C00AE.1020108@yandex.ru \
    --to=dmantipov@yandex.ru \
    --cc=15398@debbugs.gnu.org \
    --cc=_deepfire@feelingofgreen.ru \
    --cc=jan.h.d@swipnet.se \
    --cc=skosyrev@ptsecurity.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.