I can't use the graphical version of emacs because huge display problems hide the content of the window. The characters only appear when I resize the window or when I select the characters, but they disappear as soon as something in the window is redrawn. I don't think that this problem is really caused by emacs, because when I use the feature in emacs setting a semi-transparent background (using (set-frame-parameter (selected-frame) 'alpha '(85 50)) in ~/.emacs), the title bar of the window (managed by mutter, not related to emacs code AFAIK) has drawing problems too. So I think that it's probably a bug in mutter, gnome-shell, X, mesa or intel drivers. With a normal background, the bug is only visible inside the window. I use some non-standard packages in gentoo (for example dev versions of gnome packages), I don't know if it's related, but other users may have this problem with the official ebuilds and/or you may be interested in solving this bug before these packages come in the official repository. A video showing the problem is attached.
Created attachment 369672 [details] Video showing the problem
Which versions of all those packages are you using? From which overlays do they come, or do they come from just Gentoo? Is this the first time you experience this on a totally new install or as a new desktop environment, or is this a regression compared to a previous version? Thank you having attached that video, it demonstrates the problem quite well.
media-libs/mesa-10.0.3 USE="classic egl gallium gbm llvm nptl openvg" x11-wm/mutter-3.11.4::gnome-next USE="introspection" x11-base/xorg-server-1.15.0 USE="ipv6 nptl suid udev xorg" x11-drivers/xf86-video-intel-2.99.909 USE="dri sna udev" I have the same results with these two ebuilds for emacs: app-editors/emacs-vcs-24.3.9999::emacs or app-editors/emacs-24.3-r2 USE="X acl alsa dbus gif gnutls gsettings gtk gtk3 imagemagick inotify jpeg png sound svg xft xpm zlib" I have ebuilds installed from these overlays on my system: bleeding-edge, emacs, gnome-next, steam and sunrise. It's a regression that appeared about one month ago. Before that, I had another problem in emacs, the cursor was not totally erased when moved (the cursor in emacs, not the mouse). The last time everything worked fine was ~3 months ago. Of course, Emacs works fine in a terminal (well, actually it's a pain to use :p). In the video, I've used an alpha of 5% for emacs (set-frame-parameter (selected-frame) 'alpha '(5 50)) because it's easier to see that the problem is also present on the title bar. When there's no transparency, the caracters don't disappear smoothly as they do in the video, they are erased as soon as the window is redrawed, and the title bar is normal.
Please post the output of "emerge --info". (In reply to Guillaume Ayoub from comment #3) > app-editors/emacs-24.3-r2 USE="X acl alsa dbus gif gnutls gsettings gtk > gtk3 imagemagick inotify jpeg png sound svg xft xpm zlib" > > It's a regression that appeared about one month ago. Before that, I had > another problem in emacs, the cursor was not totally erased when moved (the > cursor in emacs, not the mouse). The last time everything worked fine was ~3 > months ago. emacs-24.3-r2 is in the tree since May 2013, so it's unlikely that any regressions would be due to Emacs.
Created attachment 369706 [details] emerge --info
What gnome-shell / mutter versions
(In reply to Pacho Ramos from comment #6) > What gnome-shell / mutter versions mutter 3.11.4 and gnome-shell 3.11.3, from the gnome-next overlay.
Well, it's Heather's overlay if I don't misremember, anyway, I think it could be a gnome-shell/mutter upstream problem
(In reply to Pacho Ramos from comment #8) > Well, it's Heather's overlay if I don't misremember, anyway, I think it > could be a gnome-shell/mutter upstream problem I have the same problem under fluxbox (ebuild from the standard Gentoo repository). It's even worst: the desktop background is not redrawn. I've also tried to switch between SNA and UXA acceleration methods for the intel driver, I get the same result with both results.
Emacs didn't even start with gtk+-3.11.5, but the bug is fixed with gtk+-3.11.6.
Good to hear it :) I'm trying to get 3.11.90 now.
