Problems with compositing-enabled metacity in gnome enviroment

Problems with compositing-enabled metacity in gnome enviroment

[Darren Hoo]

Hi,

   with /apps/metacity/general/compositing_manager set to true
and (setf (frame-parameter nil 'alpha) 94), once  Emacs  is minimized
it can no longer be restored. This is the commit that introduces the bug:

Author: Stefan Monnier <monnier@iro.umontreal.ca>  2010-12-19 13:43:42
Committer: Stefan Monnier <monnier@iro.umontreal.ca>  2010-12-19 13:43:42
Parent: e92a45321e9a32e78cd4233d0a030f435ffa487f (Add missing
ChangeLog entry for r102680.)
Branches: master, remotes/origin/lexbind-new, remotes/origin/master,
remotes/origin/window-pub
Follows: EMACS_PRETEST_23_2_91
Precedes:

    Minor clean up to silence some gcc warnings.
    * src/window.c (Fset_window_buffer):
    * src/xterm.c (x_set_frame_alpha): Restructure code to silence
    compiler warning.
    (handle_one_xevent): Remove unused var `p'.
    (do_ewmh_fullscreen): Remove unused var `lval'.
    (xembed_set_info): Remove unused var `atom'.
    * src/textprop.c (Fremove_list_of_text_properties): Add braces to silence
    compiler warning.
    * src/fontset.c (fontset_id_valid_p, dump_fontset):
    * src/ftfont.c (ftfont_drive_otf): Modernize k&r declaration.
    * src/eval.c (Feval, Ffuncall): Avoid unneeded gotos.
    * src/dispnew.c (update_frame, update_frame_1): Compile the `do_pause'
    label only when it's used.
    * src/image.c (x_create_bitmap_from_xpm_data):
    * src/dispextern.h (x_create_bitmap_from_xpm_data): Use const char** like
    its callers.
    * src/coding.c (detect_coding_utf_16): Remove unused vars `src_base' and
    `consumed_chars'.
    (DECODE_EMACS_MULE_21_COMPOSITION): Remove unused var `charbuf_base'.
    (decode_coding_emacs_mule): Remove unused label `retry'.
    (detect_eol): Add parens to silence compiler warning.
    * src/alloc.c (bytes_used_when_reconsidered): Move to the #ifdef where
    it's used to silence the compiler.
    (make_number): Modernize k&r declaration.
    (mark_char_table): Add parens to silence compiler warning.

Re: Problems with compositing-enabled metacity in gnome enviroment

[Jan Djärv]

Hello.

I can easily reproduce this bug.  Emacs does get restored, but metacity is
buggy, and doesn't draw the window correctly.  Other apps also don't redraw 
correctly with metacity and compositing_manager true.  For example, Chromium 
menus don't pop down and are left on the screen, the Gnome panel sometimes 
vanishes, and so on.  If you wan't compositing_manager use compiz, it is 
nowhere near as buggy as metacity.  Emacs (and other apps) works fine with it.

BTW, you probably meant (set-frame-parameter nil 'alpha 94).  Also, please use 
report-emacs-bug for bugs like these.

2011-02-10 19:29, Darren Hoo skrev:
> Hi,
>
>     with /apps/metacity/general/compositing_manager set to true
> and (setf (frame-parameter nil 'alpha) 94), once  Emacs  is minimized
> it can no longer be restored. This is the commit that introduces the bug:

I reverted to the version before this commit, but the bug in metacity remains. 
  It is probably a fluke that your meatcity works with that version.

	Jan D.

Re: Problems with compositing-enabled metacity in gnome enviroment

[Darren Hoo]

Hi Jan

On Fri, Feb 11, 2011 at 9:52 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> I can easily reproduce this bug.  Emacs does get restored, but metacity is
> buggy, and doesn't draw the window correctly.  Other apps also don't redraw
> correctly with metacity and compositing_manager true.  For example, Chromium
> menus don't pop down and are left on the screen, the Gnome panel sometimes
> vanishes, and so on.  If you wan't compositing_manager use compiz, it is
> nowhere near as buggy as metacity.  Emacs (and other apps) works fine with
> it.

The version of  metacity I am using is 2.30.1-3 in Debian Unstable. Is
there any related
bug report of metacity that I can refer to?

I had experienced the varnishes of  Gnome panel a long time ago, But
since then I
never experience it for at least half a year, aslo with  Chromium I
never encounter
such  symptoms as you mentioned.

The only thing I want with compositing is the fancy tranparency of
Emacs, switching to
compiz seems not to be a choice for me, compiz is somewhat over-bloated to me.

>
> BTW, you probably meant (set-frame-parameter nil 'alpha 94).  Also, please
> use report-emacs-bug for bugs like these.
Got it

> I reverted to the version before this commit, but the bug in metacity remains.  It is
> probably a fluke that your meatcity works with > that version.

just FYI,  it is this specific hunk of the commit that triggers the
(possible) bug of metacity
Just revert this hunk of the commit Emacs works as expected at least for me.

src/xterm.c:

@@ -489,14 +489,14 @@ x_set_frame_alpha (struct frame *f)
 			     &data);

     if (rc == Success && actual != None)
-      if (*(unsigned long *)data == opac)
-	{
-	  XFree ((void *) data);
-	  x_uncatch_errors ();
-	  return;
-	}
-      else
+      {
 	XFree ((void *) data);
+	if (*(unsigned long *)data == opac)
+	  {
+	    x_uncatch_errors ();
+	    return;
+	  }
+      }
     x_uncatch_errors ();
   }



Thanks,

Darren.

Re: Problems with compositing-enabled metacity in gnome enviroment

[Jan Djärv]

2011-02-11 15:53, Darren Hoo skrev:

> The version of  metacity I am using is 2.30.1-3 in Debian Unstable. Is
> there any related
> bug report of metacity that I can refer to?

No, but I guess you can file one.  BTW, I got 2.30.2-0 in ubuntu, and I always 
get the bug you see, even with emacs-23 that hasn't the commit you mention below.

>
> I had experienced the varnishes of  Gnome panel a long time ago, But
> since then I
> never experience it for at least half a year, aslo with  Chromium I
> never encounter
> such  symptoms as you mentioned.
>
> The only thing I want with compositing is the fancy tranparency of
> Emacs, switching to
> compiz seems not to be a choice for me, compiz is somewhat over-bloated to me.
>
>>
>> BTW, you probably meant (set-frame-parameter nil 'alpha 94).  Also, please
>> use report-emacs-bug for bugs like these.
> Got it
>
>> I reverted to the version before this commit, but the bug in metacity remains.  It is
>> probably a fluke that your meatcity works with>  that version.
>
> just FYI,  it is this specific hunk of the commit that triggers the
> (possible) bug of metacity
> Just revert this hunk of the commit Emacs works as expected at least for me.
>
> src/xterm.c:
>
> @@ -489,14 +489,14 @@ x_set_frame_alpha (struct frame *f)
>   			&data);
>
>       if (rc == Success&&  actual != None)
> -      if (*(unsigned long *)data == opac)
> -	{
> -	  XFree ((void *) data);
> -	  x_uncatch_errors ();
> -	  return;
> -	}
> -      else
> +      {
>   	XFree ((void *) data);
> +	if (*(unsigned long *)data == opac)
> +	  {
> +	    x_uncatch_errors ();
> +	    return;
> +	  }
> +      }
>       x_uncatch_errors ();
>     }

Ouch, this looks really bad.  Not only is data accesses after it has been 
free:d, but we may be doing catch errors twice and uncatch only once.

I fixed this, see if it works with your metacity.  It doesn't for me.

	Jan D.

Re: Problems with compositing-enabled metacity in gnome enviroment

[Darren Hoo]

Hi Jan,

On Sat, Feb 12, 2011 at 12:02 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> just FYI,  it is this specific hunk of the commit that triggers the
>> (possible) bug of metacity
>> Just revert this hunk of the commit Emacs works as expected at least for
>> me.
>>
>> src/xterm.c:
>>
>> @@ -489,14 +489,14 @@ x_set_frame_alpha (struct frame *f)
>>                        &data);
>>
>>      if (rc == Success&&  actual != None)
>> -      if (*(unsigned long *)data == opac)
>> -       {
>> -         XFree ((void *) data);
>> -         x_uncatch_errors ();
>> -         return;
>> -       }
>> -      else
>> +      {
>>        XFree ((void *) data);
>> +       if (*(unsigned long *)data == opac)
>> +         {
>> +           x_uncatch_errors ();
>> +           return;
>> +         }
>> +      }
>>      x_uncatch_errors ();
>>    }
>
> Ouch, this looks really bad.  Not only is data accesses after it has been
> free:d, but we may be doing catch errors twice and uncatch only once.

Yes, comparsion after data has been freed,  it does not return and continues
to execute  XChangeProperty afterwards.

>
> I fixed this, see if it works with your metacity.  It doesn't for me.

I double checked this, revert this hunk works for me.


Darren.