bug#20677: tooltips generate garbage

bug#20677: tooltips generate garbage

[Angelo Graziosi]

After tooltips show up, they do not disappear moving the mouse but leave 
garbage in the Emacs frame.

I see this (on GNU/Linux, GTK build) in recent Emacs master.

This DID NOT happen with the builds I did a few week ago (May 13).

Usually "emacs -Q" is enough to see this issue. It seems a redrawing 
problem because when I click on the upper-right '-' button which reduce 
Emacs to an icon in status bar and then re-enlarging, the garbage 
disappears (but re-appears if the mouse pointer is over an element which 
needs a tooltip).


Ciao,
  Angelo.

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> Date: Wed, 27 May 2015 23:40:33 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> 
> After tooltips show up, they do not disappear moving the mouse but leave 
> garbage in the Emacs frame.
> 
> I see this (on GNU/Linux, GTK build) in recent Emacs master.
> 
> This DID NOT happen with the builds I did a few week ago (May 13).

Please try bisecting, as I don't see it here.

bug#20677: tooltips generate garbage

[Angelo Graziosi]

Il 28/05/2015 04:43, Eli Zaretskii ha scritto:
>> Date: Wed, 27 May 2015 23:40:33 +0200
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>>
>> After tooltips show up, they do not disappear moving the mouse but leave
>> garbage in the Emacs frame.
>>
>> I see this (on GNU/Linux, GTK build) in recent Emacs master.
>>
>> This DID NOT happen with the builds I did a few week ago (May 13).
>
> Please try bisecting, as I don't see it here.
>

OK. This master,


http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-7ac84a2570e1268cc040fcd529508307b2b22c01.tar.gz

(http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7ac84a2570e1268cc040fcd529508307b2b22c01)

works as expected.

Instead the next,


http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-ee14727ce033bae3bc11af35e7843604e5a5e635.tar.gz

(http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ee14727ce033bae3bc11af35e7843604e5a5e635)

shows the tooltip garbage I described.

For what I can see, the issue regards only the GTK build on GNU/Linux 
(Linux Mint 17.1 64 bit, with GTK+ 3.10)

Ciao,
  Angelo.

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> Date: Mon, 01 Jun 2015 13:46:54 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se
> 
> OK. This master,
> 
> 
> http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-7ac84a2570e1268cc040fcd529508307b2b22c01.tar.gz
> 
> (http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7ac84a2570e1268cc040fcd529508307b2b22c01)
> 
> works as expected.
> 
> Instead the next,
> 
> 
> http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-ee14727ce033bae3bc11af35e7843604e5a5e635.tar.gz
> 
> (http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ee14727ce033bae3bc11af35e7843604e5a5e635)
> 
> shows the tooltip garbage I described.
> 
> For what I can see, the issue regards only the GTK build on GNU/Linux 
> (Linux Mint 17.1 64 bit, with GTK+ 3.10)

Looks like the Cairo merge caused this.  Jan, could you take a look,
please?

Thanks.

bug#20677: tooltips generate garbage

[Angelo Graziosi]

Il 01/06/2015 16:36, Eli Zaretskii ha scritto:
>> Date: Mon, 01 Jun 2015 13:46:54 +0200
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se
>>
>> OK. This master,
>>
>>
>> http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-7ac84a2570e1268cc040fcd529508307b2b22c01.tar.gz
>>
>> (http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7ac84a2570e1268cc040fcd529508307b2b22c01)
>>
>> works as expected.
>>
>> Instead the next,
>>
>>
>> http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-ee14727ce033bae3bc11af35e7843604e5a5e635.tar.gz
>>
>> (http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ee14727ce033bae3bc11af35e7843604e5a5e635)
>>
>> shows the tooltip garbage I described.
>>
>> For what I can see, the issue regards only the GTK build on GNU/Linux
>> (Linux Mint 17.1 64 bit, with GTK+ 3.10)
>
> Looks like the Cairo merge caused this.  Jan, could you take a look,
> please?

Hmm... given the issue and looking at the changes, this caught my attention:

--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3824,8 +3824,7 @@ xg_update_scrollbar_pos (struct frame *f,
               above.  */
  	  oldw += (scale - 1) * oldw;
  	  oldx -= (scale - 1) * oldw;
-          x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
-                        oldx, oldy, oldw, oldh);
+          x_clear_area (f, oldx, oldy, oldw, oldh);

maybe, on linux+X Emacs needs something like this

# if def(...X11..)
   [...]
   x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)...
#else
   x_clear_area (f, oldx, oldy, oldw, oldh)...
#endif


Ciao,
   Angelo.

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> Date: Mon, 01 Jun 2015 17:58:36 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se
> 
> Hmm... given the issue and looking at the changes, this caught my attention:
> 
> --- a/src/gtkutil.c
> +++ b/src/gtkutil.c
> @@ -3824,8 +3824,7 @@ xg_update_scrollbar_pos (struct frame *f,
>                above.  */
>   	  oldw += (scale - 1) * oldw;
>   	  oldx -= (scale - 1) * oldw;
> -          x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
> -                        oldx, oldy, oldw, oldh);
> +          x_clear_area (f, oldx, oldy, oldw, oldh);
> 
> maybe, on linux+X Emacs needs something like this
> 
> # if def(...X11..)
>    [...]
>    x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)...
> #else
>    x_clear_area (f, oldx, oldy, oldw, oldh)...
> #endif

No, the calling sequence of x_clear_area has changed, so that change
was correct, I think.  Are you saying that reverting it makes tooltips
work again?

bug#20677: tooltips generate garbage

[Angelo Graziosi]

Il 01/06/2015 18:19, Eli Zaretskii ha scritto:
>> Date: Mon, 01 Jun 2015 17:58:36 +0200
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se
>>
>> Hmm... given the issue and looking at the changes, this caught my attention:
>>
>> --- a/src/gtkutil.c
>> +++ b/src/gtkutil.c
>> @@ -3824,8 +3824,7 @@ xg_update_scrollbar_pos (struct frame *f,
>>                 above.  */
>>    	  oldw += (scale - 1) * oldw;
>>    	  oldx -= (scale - 1) * oldw;
>> -          x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
>> -                        oldx, oldy, oldw, oldh);
>> +          x_clear_area (f, oldx, oldy, oldw, oldh);
>>
>> maybe, on linux+X Emacs needs something like this
>>
>> # if def(...X11..)
>>     [...]
>>     x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)...
>> #else
>>     x_clear_area (f, oldx, oldy, oldw, oldh)...
>> #endif
>
> No, the calling sequence of x_clear_area has changed, so that change
> was correct, I think.  Are you saying that reverting it makes tooltips
> work again?

Really I didn't tested that.. Eventually, I will test that over the next 
few days..

bug#20677: tooltips generate garbage

[Wolfgang Jenkner]

On Mon, Jun 01 2015, Angelo Graziosi wrote:

> maybe, on linux+X Emacs needs something like this
>
> # if def(...X11..)
>   [...]
>   x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)...


The commit log says

    (USE_CAIRO): Default to yes for Gtk+ 3.  Add code to test for cairo,

So I guess x_clear_area uses the new cairo specific code in your case.

You could try to configure --without-cairo.

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> Date: Mon, 01 Jun 2015 23:55:55 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se
> 
> Il 01/06/2015 18:19, Eli Zaretskii ha scritto:
> >> Date: Mon, 01 Jun 2015 17:58:36 +0200
> >> From: Angelo Graziosi <angelo.graziosi@alice.it>
> >> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se
> >>
> >> Hmm... given the issue and looking at the changes, this caught my attention:
> >>
> >> --- a/src/gtkutil.c
> >> +++ b/src/gtkutil.c
> >> @@ -3824,8 +3824,7 @@ xg_update_scrollbar_pos (struct frame *f,
> >>                 above.  */
> >>    	  oldw += (scale - 1) * oldw;
> >>    	  oldx -= (scale - 1) * oldw;
> >> -          x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
> >> -                        oldx, oldy, oldw, oldh);
> >> +          x_clear_area (f, oldx, oldy, oldw, oldh);
> >>
> >> maybe, on linux+X Emacs needs something like this
> >>
> >> # if def(...X11..)
> >>     [...]
> >>     x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)...
> >> #else
> >>     x_clear_area (f, oldx, oldy, oldw, oldh)...
> >> #endif
> >
> > No, the calling sequence of x_clear_area has changed, so that change
> > was correct, I think.  Are you saying that reverting it makes tooltips
> > work again?
> 
> Really I didn't tested that.. Eventually, I will test that over the next 
> few days..

Can you show a screenshot of the bad tooltip display?

bug#20677: tooltips generate garbage

[Angelo Graziosi]

Il 02/06/2015 02:31, Wolfgang Jenkner ha scritto:
> On Mon, Jun 01 2015, Angelo Graziosi wrote:
>
>> maybe, on linux+X Emacs needs something like this
>>
>> # if def(...X11..)
>>    [...]
>>    x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)...
>
>
> The commit log says
>
>      (USE_CAIRO): Default to yes for Gtk+ 3.  Add code to test for cairo,
>
> So I guess x_clear_area uses the new cairo specific code in your case.
>
> You could try to configure --without-cairo.
>

I tried that but doesn't work..

bug#20677: tooltips generate garbage

[Angelo Graziosi]

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



Il 02/06/2015 04:33, Eli Zaretskii ha scritto:
>> Date: Mon, 01 Jun 2015 23:55:55 +0200
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se
>>
>> Il 01/06/2015 18:19, Eli Zaretskii ha scritto:
>>>> Date: Mon, 01 Jun 2015 17:58:36 +0200
>>>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>>>> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se
>>>>
>>>> Hmm... given the issue and looking at the changes, this caught my attention:
>>>>
>>>> --- a/src/gtkutil.c
>>>> +++ b/src/gtkutil.c
>>>> @@ -3824,8 +3824,7 @@ xg_update_scrollbar_pos (struct frame *f,
>>>>                  above.  */
>>>>     	  oldw += (scale - 1) * oldw;
>>>>     	  oldx -= (scale - 1) * oldw;
>>>> -          x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
>>>> -                        oldx, oldy, oldw, oldh);
>>>> +          x_clear_area (f, oldx, oldy, oldw, oldh);
>>>>
>>>> maybe, on linux+X Emacs needs something like this
>>>>
>>>> # if def(...X11..)
>>>>      [...]
>>>>      x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)...
>>>> #else
>>>>      x_clear_area (f, oldx, oldy, oldw, oldh)...
>>>> #endif
>>>
>>> No, the calling sequence of x_clear_area has changed, so that change
>>> was correct, I think.  Are you saying that reverting it makes tooltips
>>> work again?
>>
>> Really I didn't tested that.. Eventually, I will test that over the next
>> few days..
>
> Can you show a screenshot of the bad tooltip display?
>

Attached. (Schermata2.png is with "emacs -Q &")


[-- Attachment #2: screenshot.tar.gz --]
[-- Type: application/gzip, Size: 179367 bytes --]

bug#20677: tooltips generate garbage

[Angelo Graziosi]

Il 02/06/2015 11:23, Angelo Graziosi ha scritto:
>
>
> Il 02/06/2015 04:33, Eli Zaretskii ha scritto:

>>
>> Can you show a screenshot of the bad tooltip display?
>>
>
> Attached. (Schermata2.png is with "emacs -Q &")

Just for clarification...

When I move the mouse pointer over an icon which has a tooltip, this is 
shown correctly. It is when I move the pointer so that the tooltip 
should be "closed" that it, partially, remains as shown by screenshots I 
sent.

Whit "emacs -Q" It is a bit more complicated to reproduce the issue: 
only the tooltips of a few icons give it.

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> Date: Tue, 02 Jun 2015 11:35:02 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: 20677@debbugs.gnu.org
> 
> > Attached. (Schermata2.png is with "emacs -Q &")
> 
> Just for clarification...
> 
> When I move the mouse pointer over an icon which has a tooltip, this is 
> shown correctly. It is when I move the pointer so that the tooltip 
> should be "closed" that it, partially, remains as shown by screenshots I 
> sent.

Yes, that's what I deduced from your screenshots, thanks.

So it probably means the problem is with x-hide-tip, not with
x-show-tip.  Somehow, we don't redraw the parts of the frame that were
overlaid with the tooltip, when the tip pops down, and the artifacts
from the tooltip display stay on screen.

Does Emacs clean up the display if you type "M-x redraw-display RET"
after the tip pops down?  What about covering the frame with the tip
artifacts with another frame, then uncovering it -- does the frame get
redrawn automatically, and does that remove the artifacts?

Finally, can you try setting x-gtk-use-system-tooltips to nil, and see
if that makes the problem go away?

bug#20677: tooltips generate garbage

[Michael Heerdegen]

Hello Eli,

I see this problem, too.  Quickly tested your questions with my
configuration.

> Does Emacs clean up the display if you type "M-x redraw-display RET"
> after the tip pops down?

Yes.

>  What about covering the frame with the tip artifacts with another
> frame, then uncovering it -- does the frame get redrawn automatically,
> and does that remove the artifacts?

Yes, it does.  Switching to another frame also removes the artifacts.

> Finally, can you try setting x-gtk-use-system-tooltips to nil, and see
> if that makes the problem go away?

Yes, that helps.

Reverting 7927a4 as suggested somewhere else in this thread also fixes
the problem for me.


Michael.

bug#20677: tooltips generate garbage

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Reverting 7927a4 as suggested somewhere else in this thread also fixes
> the problem for me.

Mmh, wait, I tested too superficially.  Reverting this change and "make"
doesn't make a difference.  Will try again with "make bootstrap"...

bug#20677: tooltips generate garbage

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Mmh, wait, I tested too superficially.  Reverting this change and "make"
> doesn't make a difference.  Will try again with "make bootstrap"...

... no, reverting that change _doesn't_ make a difference here.

BTW, in dired, I can always reproduce the problem by hovering with the
mouse.  Where text is displayed, the artifact is not visible, only on
regions where the buffer is empty.

OTOH, in *Packages*, tooltips don't leave artifacts at all.

Michael.

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Angelo Graziosi <angelo.graziosi@alice.it>,  20677@debbugs.gnu.org
> Date: Tue, 02 Jun 2015 17:31:55 +0200
> 
> I see this problem, too.  Quickly tested your questions with my
> configuration.

Thanks.

> > Does Emacs clean up the display if you type "M-x redraw-display RET"
> > after the tip pops down?
> 
> Yes.
> 
> >  What about covering the frame with the tip artifacts with another
> > frame, then uncovering it -- does the frame get redrawn automatically,
> > and does that remove the artifacts?
> 
> Yes, it does.  Switching to another frame also removes the artifacts.
> 
> > Finally, can you try setting x-gtk-use-system-tooltips to nil, and see
> > if that makes the problem go away?
> 
> Yes, that helps.

OK, so it seems my guess was correct: we don't redraw the portions of
display that were obscured by the tooltip.

> Reverting 7927a4 as suggested somewhere else in this thread also fixes
> the problem for me.

I don't understand this.  After reverting it, what does "git diff" say
about the differences between what you have and current master HEAD?
If it's just the diffs below (which is the reverse of what I see if I
type "git show 7927a4"), then how can the result work, when
x_clear_area now has this signature:

  void x_clear_area (struct frame *f, int x, int y, int width, int height);

IOW, reverting 7927a4 seems to cause us call x_clear_area with a wrong
argument list.  How does this even compile?  What am I missing?

diff --git a/src/xfns.c b/src/xfns.c
index 5ac58e9..16a568e 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -1084,7 +1084,8 @@ struct x_display_info *
 	  y = FRAME_TOP_MARGIN_HEIGHT (f);
 
 	  block_input ();
-	  x_clear_area (f, 0, y, width, height);
+	  x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
+			0, y, width, height);
 	  unblock_input ();
 	}
 
@@ -1095,8 +1094,7 @@ struct x_display_info *
 	  height = nlines * FRAME_LINE_HEIGHT (f) - y;
 
 	  block_input ();
-	  x_clear_area (f, 0, y, width, height);
+	  x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
+			0, y, width, height);
 	  unblock_input ();
 	}
 

bug#20677: tooltips generate garbage

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > Reverting 7927a4 as suggested somewhere else in this thread also
> > fixes the problem for me.
>
> I don't understand this.

Yip, I was wrong, sorry for the confusion...

Michael.

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 20677@debbugs.gnu.org,  Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Tue, 02 Jun 2015 17:54:27 +0200
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > Mmh, wait, I tested too superficially.  Reverting this change and "make"
> > doesn't make a difference.  Will try again with "make bootstrap"...
> 
> ... no, reverting that change _doesn't_ make a difference here.

Does it even compile?  I think it shouldn't compile.  Or maybe I'm
missing something.

> BTW, in dired, I can always reproduce the problem by hovering with the
> mouse.  Where text is displayed, the artifact is not visible, only on
> regions where the buffer is empty.

So this probably means we don't clear the area that was obscured by
the tip, we only redisplay the text in the obscured region.  Does this
match what you see?

Can you see whether Emacs gets an expose event when the tip pops down?

bug#20677: tooltips generate garbage

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Does it even compile?  I think it shouldn't compile.  Or maybe I'm
> missing something.

I tried "make" again, and it compiles.  I'm now trying bootstrapping
again to see if I missed an error message.

> So this probably means we don't clear the area that was obscured by
> the tip, we only redisplay the text in the obscured region.  Does this
> match what you see?

Could be.  Testing with a buffer in fundamental-mode and

   M-: (insert (propertize "test" 'help-echo "-----------------"))

seems to confirm this when I add more text etc.

> Can you see whether Emacs gets an expose event when the tip pops down?

Sorry, you've found my limit in understanding.  How can check that?


Michael.

bug#20677: tooltips generate garbage

[Angelo Graziosi]

Il 02/06/2015 18:02, Eli Zaretskii ha scritto:
>
> IOW, reverting 7927a4 seems to cause us call x_clear_area with a wrong
> argument list.  How does this even compile?  What am I missing?

I tried this in gtkutil.c

+          x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
+                        oldx, oldy, oldw, oldh);
-          x_clear_area (f, oldx, oldy, oldw, oldh);

and it didn't compile (wrong number of arguments)...

I don't understand this:

>
> diff --git a/src/xfns.c b/src/xfns.c
> index 5ac58e9..16a568e 100644
> --- a/src/xfns.c
> +++ b/src/xfns.c
> @@ -1084,7 +1084,8 @@ struct x_display_info *
>   	  y = FRAME_TOP_MARGIN_HEIGHT (f);
>
>   	  block_input ();
> -	  x_clear_area (f, 0, y, width, height);
> +	  x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
> +			0, y, width, height);
>   	  unblock_input ();
>   	}
>
> @@ -1095,8 +1094,7 @@ struct x_display_info *
>   	  height = nlines * FRAME_LINE_HEIGHT (f) - y;
>
>   	  block_input ();
> -	  x_clear_area (f, 0, y, width, height);
> +	  x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
> +			0, y, width, height);
>   	  unblock_input ();
>   	}


remember that

   79bbe53a991007036ce9bcf897a4ce1371f516ea  2015-05-23 09:21:27 (GMT)

works as expected, while

  ee14727ce033bae3bc11af35e7843604e5a5e635   2015-05-23 10:27:56 (GMT)

shows the issue, and ee14727ce033bae3bc1... has already xfns.c with that 
above (+) code..

bug#20677: tooltips generate garbage

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Does it even compile?  I think it shouldn't compile.  Or maybe I'm
> missing something.

I guess I was not reverting what you had in mind.  I was reverting
7927a4a - probably not the commit you were speaking about.

Michael.

bug#20677: tooltips generate garbage

[Wolfgang Jenkner]

On Tue, Jun 02 2015, Eli Zaretskii wrote:

> Or maybe I'm missing something.

Yes, the surrounding preprocessor conditional... (the commit message
hints at that as well).

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> Date: Tue, 02 Jun 2015 19:04:39 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: 20677@debbugs.gnu.org
> 
> remember that
> 
>    79bbe53a991007036ce9bcf897a4ce1371f516ea  2015-05-23 09:21:27 (GMT)
> 
> works as expected, while
> 
>   ee14727ce033bae3bc11af35e7843604e5a5e635   2015-05-23 10:27:56 (GMT)
> 
> shows the issue, and ee14727ce033bae3bc1... has already xfns.c with that 
> above (+) code..


AFAIU, the changes between these two commits include the entire Cairo
merge, so I see no way to use this information to find the problem in
an efficient way.  For all I know, it could simply be an omission in
the Cairo related code, not something introduced by the merge.

The only way of finding the problem is debug this in the current
codebase.

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 20677@debbugs.gnu.org,  angelo.graziosi@alice.it
> Date: Tue, 02 Jun 2015 18:33:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does it even compile?  I think it shouldn't compile.  Or maybe I'm
> > missing something.
> 
> I tried "make" again, and it compiles.  I'm now trying bootstrapping
> again to see if I missed an error message.

The code is in non-GTK portion, so the compiler doesn't see it when
you build with GTK.  That's why it doesn't complain in that
configuration, and that's why reverting that change cannot have any
effect on the GTK build.

> > Can you see whether Emacs gets an expose event when the tip pops down?
> 
> Sorry, you've found my limit in understanding.  How can check that?

The function expose_frame (defined in xdisp.c) should be called when
such an event comes in.

If your Emacs was configured with --enable-checking='yes,glyphs', then
you can see the fact that the function is called announced on stderr
after invoking "M-x trace-redisplay RET".  (If you do that, I suggest
to turn off blink-cursor-mode first, to reduce clutter from redisplay
cycles induced by the blinking.)

Alternatively, put a breakpoint at entry to expose_frame, and see if
it's called when the tip pops down.

The call should come from handle_one_xevent in xterm.c, where you will
see that the call to x_clear_area is not done in the Cairo build --
this could be the culprit, perhaps at least when the GTK tooltip was
just popped down.

Caveat: please note that I have no idea what does using Cairo change
in how Emacs interacts with X, I'm just making stabs in the dark at
this point.

Thanks.

bug#20677: tooltips generate garbage

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 02 Jun 2015 22:08:59 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> > Can you see whether Emacs gets an expose event when the tip pops down?
>> 
>> Sorry, you've found my limit in understanding.  How can check that?

> The function expose_frame (defined in xdisp.c) should be called when
> such an event comes in.

Could those who see this problem try the following patches, one at a
time?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[FIRST]
diff --git a/src/xterm.c b/src/xterm.c
index 25c0d87..691ede5 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -7668,7 +7668,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
             }
           else
 	    {
-#if defined (USE_GTK) && ! defined (HAVE_GTK3) && ! defined (USE_CAIRO)
+#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 (f,


[SECOND]
diff --git a/src/xterm.c b/src/xterm.c
index 25c0d87..32d4d3a 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -7668,12 +7668,14 @@ handle_one_xevent (struct x_display_info *dpyinfo,
             }
           else
 	    {
-#if defined (USE_GTK) && ! defined (HAVE_GTK3) && ! defined (USE_CAIRO)
+#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 (f,
-			    event->xexpose.x, event->xexpose.y,
-			    event->xexpose.width, event->xexpose.height);
+	      x_clear_area1 (event->xexpose.display,
+			     event->xexpose.window,
+			     event->xexpose.x, event->xexpose.y,
+			     event->xexpose.width, event->xexpose.height,
+			     False);
 #endif
 	      expose_frame (f, event->xexpose.x, event->xexpose.y,
 			    event->xexpose.width, event->xexpose.height);

bug#20677: tooltips generate garbage

[Angelo Graziosi]

Il 03/06/2015 09:01, YAMAMOTO Mitsuharu ha scritto:
>>>>>> On Tue, 02 Jun 2015 22:08:59 +0300, Eli Zaretskii <eliz@gnu.org> said:
>
>>>> Can you see whether Emacs gets an expose event when the tip pops down?
>>>
>>> Sorry, you've found my limit in understanding.  How can check that?
>
>> The function expose_frame (defined in xdisp.c) should be called when
>> such an event comes in.
>
> Could those who see this problem try the following patches, one at a
> time?

Here (GNU/Linux Mint 17.1 Mate 64bit) both patches seem to work fine!

  Ciao,
    Angelo.

>
> [FIRST]
> diff --git a/src/xterm.c b/src/xterm.c
> index 25c0d87..691ede5 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -7668,7 +7668,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
>               }
>             else
>   	    {
> -#if defined (USE_GTK) && ! defined (HAVE_GTK3) && ! defined (USE_CAIRO)
> +#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 (f,
>
>
> [SECOND]
> diff --git a/src/xterm.c b/src/xterm.c
> index 25c0d87..32d4d3a 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -7668,12 +7668,14 @@ handle_one_xevent (struct x_display_info *dpyinfo,
>               }
>             else
>   	    {
> -#if defined (USE_GTK) && ! defined (HAVE_GTK3) && ! defined (USE_CAIRO)
> +#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 (f,
> -			    event->xexpose.x, event->xexpose.y,
> -			    event->xexpose.width, event->xexpose.height);
> +	      x_clear_area1 (event->xexpose.display,
> +			     event->xexpose.window,
> +			     event->xexpose.x, event->xexpose.y,
> +			     event->xexpose.width, event->xexpose.height,
> +			     False);
>   #endif
>   	      expose_frame (f, event->xexpose.x, event->xexpose.y,
>   			    event->xexpose.width, event->xexpose.height);
>

bug#20677: tooltips generate garbage

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > > Can you see whether Emacs gets an expose event when the tip pops
> > > down?

> If your Emacs was configured with --enable-checking='yes,glyphs', then
> you can see the fact that the function is called announced on stderr
> after invoking "M-x trace-redisplay RET".  (If you do that, I suggest
> to turn off blink-cursor-mode first, to reduce clutter from redisplay
> cycles induced by the blinking.)

I tried just that.  Whenever the tip pops down, I get one expose_frame
followed by one expose_window.


Regards,

Michael.

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 20677@debbugs.gnu.org,  angelo.graziosi@alice.it
> Date: Wed, 03 Jun 2015 18:10:00 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > > Can you see whether Emacs gets an expose event when the tip pops
> > > > down?
> 
> > If your Emacs was configured with --enable-checking='yes,glyphs', then
> > you can see the fact that the function is called announced on stderr
> > after invoking "M-x trace-redisplay RET".  (If you do that, I suggest
> > to turn off blink-cursor-mode first, to reduce clutter from redisplay
> > cycles induced by the blinking.)
> 
> I tried just that.  Whenever the tip pops down, I get one expose_frame
> followed by one expose_window.

And the patches proposed by Yamamoto-san, do they fix the problem for
you as well?

bug#20677: tooltips generate garbage

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> And the patches proposed by Yamamoto-san, do they fix the problem for
> you as well?

Yes, both patches fix the problem for me.  Like before, I tested with the
tooltips in a dired buffer.

Michael.

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 20677@debbugs.gnu.org,  angelo.graziosi@alice.it
> Date: Wed, 03 Jun 2015 19:02:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And the patches proposed by Yamamoto-san, do they fix the problem for
> > you as well?
> 
> Yes, both patches fix the problem for me.  Like before, I tested with the
> tooltips in a dired buffer.

Thanks.

So which one of them is better, and should be pushed?

bug#20677: tooltips generate garbage

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 03 Jun 2015 22:14:45 +0300, Eli Zaretskii <eliz@gnu.org> said:

>>> And the patches proposed by Yamamoto-san, do they fix the problem
>>> for you as well?
>> 
>> Yes, both patches fix the problem for me.  Like before, I tested
>> with the tooltips in a dired buffer.

> Thanks.

> So which one of them is better, and should be pushed?

Thanks for testing.  The second one is closer to the code before the
cairo merge, but the first would be better if it works.

Jan, do you have any comments about this?  I guess some experimental
code has been accidentally slipped in, but just in case you have any
intentions or ideas especially about newer versions of GTK+...

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> Date: Thu, 04 Jun 2015 14:25:28 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>,
> 	20677@debbugs.gnu.org,
> 	angelo.graziosi@alice.it, "Jan D." <jan.h.d@swipnet.se>
> 
> >> Yes, both patches fix the problem for me.  Like before, I tested
> >> with the tooltips in a dired buffer.
> 
> > Thanks.
> 
> > So which one of them is better, and should be pushed?
> 
> Thanks for testing.  The second one is closer to the code before the
> cairo merge, but the first would be better if it works.

I agree that the first patch looks better, as x_clear_area1 sounds
like a helper function.  So I suggest that we push that in a couple of
days.

Thanks.

bug#20677: tooltips generate garbage

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 04 Jun 2015 18:37:51 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> > So which one of them is better, and should be pushed?
>> 
>> Thanks for testing.  The second one is closer to the code before
>> the cairo merge, but the first would be better if it works.

> I agree that the first patch looks better, as x_clear_area1 sounds
> like a helper function.  So I suggest that we push that in a couple
> of days.

I pushed the first patch in dcf18b5.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#20677: tooltips generate garbage

[Eli Zaretskii]

> Date: Fri, 05 Jun 2015 09:50:13 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>,
> 	michael_heerdegen@web.de,
> 	20677-done@debbugs.gnu.org,
> 	angelo.graziosi@alice.it
> 
> >>>>> On Thu, 04 Jun 2015 18:37:51 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
> >> > So which one of them is better, and should be pushed?
> >> 
> >> Thanks for testing.  The second one is closer to the code before
> >> the cairo merge, but the first would be better if it works.
> 
> > I agree that the first patch looks better, as x_clear_area1 sounds
> > like a helper function.  So I suggest that we push that in a couple
> > of days.
> 
> I pushed the first patch in dcf18b5.

Thanks.