unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#15398: 24.3; Frame redraw completely screwed
@ 2013-09-16 19:48 Samium Gromoff
  2013-09-16 20:53 ` Jan Djärv
  0 siblings, 1 reply; 31+ messages in thread
From: Samium Gromoff @ 2013-09-16 19:48 UTC (permalink / raw)
  To: 15398

Running Emacs from a Mate session screws redraw completely.

[deepfire@betelheise ~]$ rpm -qv gtk3 pango cairo gdk-pixbuf2 libX11 libXrender libXdamage libXcomposite libwayland-client libXext mesa-libGL libxcb mesa-libEGL | grep x86_64
gtk3-3.8.4-1.fc19.x86_64
pango-1.34.1-1.fc19.x86_64
cairo-1.12.14-2.fc19.x86_64
gdk-pixbuf2-2.28.2-1.fc19.x86_64
libX11-1.6.0-1.fc19.x86_64
libXrender-0.9.7-6.20130524git786f78fd8.fc19.x86_64
libXdamage-1.1.4-3.fc19.x86_64
libXcomposite-0.4.4-3.fc19.x86_64
libwayland-client-1.2.0-1.fc19.x86_64
libXext-1.3.2-1.fc19.x86_64
mesa-libGL-9.2-1.20130902.fc19.x86_64
libxcb-1.9-3.fc19.x86_64
mesa-libEGL-9.2-1.20130902.fc19.x86_64



In GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2)
 of 2013-08-14 on buildvm-15.phx2.fedoraproject.org
Windowing system distributor `Fedora Project', version 11.0.11402000
System Description:	Fedora release 19 (Schrödinger’s Cat)

Configured using:
 `configure '--build=x86_64-redhat-linux-gnu'
 '--host=x86_64-redhat-linux-gnu' '--program-prefix='
 '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
 '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
 '--datadir=/usr/share' '--includedir=/usr/include'
 '--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
 '--localstatedir=/var' '--sharedstatedir=/var/lib'
 '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus'
 '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff'
 '--with-xft' '--with-xpm' '--with-x-toolkit=gtk3' '--with-gpm=no'
 'build_alias=x86_64-redhat-linux-gnu'
 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
 --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
 'LDFLAGS=-Wl,-z,relro ''

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp

Minor modes in effect:
  eldoc-mode: t
  paredit-mode: t
  slime-mode: t
  diff-auto-refine-mode: t
  winner-mode: t
  show-paren-mode: t
  savehist-mode: t
  msb-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <down-mouse-4> 
<mouse-4> <double-down-mouse-4> <double-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <down-mouse-5> <mouse-5> <double-down-mouse-5> 
<double-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <switch-frame> g <return> <return> 
q <switch-frame> <switch-frame> <switch-frame> <switch-frame> 
M-x C-g <switch-frame> <down-mouse-5> <mouse-5> <down-mouse-5> 
<mouse-5> <down-mouse-5> <mouse-5> <double-down-mouse-5> 
<double-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> M-x e m C-g 
<C-print> M-x e m a - r e - b u <tab> M-b M-b M-t <tab> 
<return>

Recent messages:
When done with this frame, type C-x 5 0
Loading vc-git...done
byte-code: End of buffer [2 times]
Checking new news...
nnimap read 0k from mail.feelingofgreen.ru
Reading active file via nndraft...done
Checking new news...done
nnimap read 0k from mail.feelingofgreen.ru
Auto-saving...done
Quit [2 times]

Load-path shadows:
/home/deepfire/.emacs.d/elpa/magit-20130810.1119/.dir-locals hides /usr/share/emacs/24.3/lisp/gnus/.dir-locals

Features:
(shadow emacsbug sendmail sort shr-color color qp shr mm-archive
mail-extr gnus-async gnus-bcklg gnus-ml disp-table vc-git tmm nndraft
nnmh nnfolder utf-7 gnutls network-stream starttls nnimap parse-time tls
utf7 netrc gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig mailcap
gnus-cache gnus-sum help-mode server gnus-demon nntp gnus-group
gnus-undo nnmail mail-source gnus-start gnus-spec gnus-win nnoo gnus-int
gnus-range message rfc822 mml mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
mailheader time-stamp windmove eldoc paredit slime-fancy
slime-fontifying-fu slime-package-fu slime-references slime-scratch
slime-presentations slime-fuzzy slime-fancy-trace slime-fancy-inspector
slime-c-p-c slime-editing-commands slime-autodoc slime-parse slime-repl
slime pp hyperspec thingatpt browse-url remember org-remember
org-datetree org-jekyll org-publish org-exp ob-exp org-exp-blocks
org-agenda org warnings ob-tangle ob-ref ob-lob ob-table org-footnote
org-src ob-comint ob-keys org-pcomplete pcomplete comint ansi-color
org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob org-compat org-macs ob-eval org-loaddefs format-spec
find-func cal-menu calendar cal-loaddefs egg edmacro kmacro derived rx
diff-mode easy-mmode ffap url-parse auth-source eieio byte-opt bytecomp
byte-compile cconv password-cache url-vars electric egg-git egg-const
egg-base ediff-merg ediff-diff ediff-wind ediff-help ediff-util
ediff-mult ediff-init ediff egg-custom solarized-dark-theme
solarized-definitions sr-speedbar advice help-fns advice-preload
speedbar sb-image ezimage dframe cl-macs gv winner ring paren savehist
msb gnus gnus-ems nnheader gnus-util mail-utils mm-util mail-prsvr
wid-edit time cus-start cus-load cl cl-lib adjust-parens-autoloads
egg-autoloads elisp-slime-nav-autoloads finder-inf git-gutter+-autoloads
magit-autoloads magit-filenotify-autoloads package+-autoloads
smtpmail-multi-autoloads sr-speedbar-autoloads w3m-autoloads info
easymenu package time-date tooltip ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment lisp-mode register page menu-bar rfn-eshadow
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

-- 
--
regards,
Samium Gromoff





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: 24.3; Frame redraw completely screwed
  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
  0 siblings, 1 reply; 31+ messages in thread
From: Jan Djärv @ 2013-09-16 20:53 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: 15398

Hello.

16 sep 2013 kl. 21:48 skrev Samium Gromoff <_deepfire@feelingofgreen.ru>:

> Running Emacs from a Mate session screws redraw completely.

Like how?  What is a Mate?  Provide screenshots if you can.  Are you running Wayland? I see wayland-client below.

	Jan D.

> 
> [deepfire@betelheise ~]$ rpm -qv gtk3 pango cairo gdk-pixbuf2 libX11 libXrender libXdamage libXcomposite libwayland-client libXext mesa-libGL libxcb mesa-libEGL | grep x86_64
> gtk3-3.8.4-1.fc19.x86_64
> pango-1.34.1-1.fc19.x86_64
> cairo-1.12.14-2.fc19.x86_64
> gdk-pixbuf2-2.28.2-1.fc19.x86_64
> libX11-1.6.0-1.fc19.x86_64
> libXrender-0.9.7-6.20130524git786f78fd8.fc19.x86_64
> libXdamage-1.1.4-3.fc19.x86_64
> libXcomposite-0.4.4-3.fc19.x86_64
> libwayland-client-1.2.0-1.fc19.x86_64
> libXext-1.3.2-1.fc19.x86_64
> mesa-libGL-9.2-1.20130902.fc19.x86_64
> libxcb-1.9-3.fc19.x86_64
> mesa-libEGL-9.2-1.20130902.fc19.x86_64
> 
> 
> 
> In GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2)
> of 2013-08-14 on buildvm-15.phx2.fedoraproject.org
> Windowing system distributor `Fedora Project', version 11.0.11402000
> System Description:	Fedora release 19 (Schrödinger’s Cat)
> 
> Configured using:
> `configure '--build=x86_64-redhat-linux-gnu'
> '--host=x86_64-redhat-linux-gnu' '--program-prefix='
> '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
> '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
> '--datadir=/usr/share' '--includedir=/usr/include'
> '--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
> '--localstatedir=/var' '--sharedstatedir=/var/lib'
> '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus'
> '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff'
> '--with-xft' '--with-xpm' '--with-x-toolkit=gtk3' '--with-gpm=no'
> 'build_alias=x86_64-redhat-linux-gnu'
> 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
> -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
> 'LDFLAGS=-Wl,-z,relro ''
> 
> Important settings:
>  value of $LANG: en_US.UTF-8
>  value of $XMODIFIERS: @im=none
>  locale-coding-system: utf-8-unix
>  default enable-multibyte-characters: t
> 
> Major mode: Lisp
> 
> Minor modes in effect:
>  eldoc-mode: t
>  paredit-mode: t
>  slime-mode: t
>  diff-auto-refine-mode: t
>  winner-mode: t
>  show-paren-mode: t
>  savehist-mode: t
>  msb-mode: t
>  display-time-mode: t
>  tooltip-mode: t
>  mouse-wheel-mode: t
>  file-name-shadow-mode: t
>  global-font-lock-mode: t
>  font-lock-mode: t
>  blink-cursor-mode: t
>  auto-composition-mode: t
>  auto-encryption-mode: t
>  auto-compression-mode: t
>  column-number-mode: t
>  line-number-mode: t
>  transient-mark-mode: t
> 
> Recent input:
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <down-mouse-4> 
> <mouse-4> <double-down-mouse-4> <double-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
> <triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
> <triple-mouse-4> <down-mouse-5> <mouse-5> <double-down-mouse-5> 
> <double-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
> <triple-mouse-5> <switch-frame> g <return> <return> 
> q <switch-frame> <switch-frame> <switch-frame> <switch-frame> 
> M-x C-g <switch-frame> <down-mouse-5> <mouse-5> <down-mouse-5> 
> <mouse-5> <down-mouse-5> <mouse-5> <double-down-mouse-5> 
> <double-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
> <triple-down-mouse-5> <triple-mouse-5> M-x e m C-g 
> <C-print> M-x e m a - r e - b u <tab> M-b M-b M-t <tab> 
> <return>
> 
> Recent messages:
> When done with this frame, type C-x 5 0
> Loading vc-git...done
> byte-code: End of buffer [2 times]
> Checking new news...
> nnimap read 0k from mail.feelingofgreen.ru
> Reading active file via nndraft...done
> Checking new news...done
> nnimap read 0k from mail.feelingofgreen.ru
> Auto-saving...done
> Quit [2 times]
> 
> Load-path shadows:
> /home/deepfire/.emacs.d/elpa/magit-20130810.1119/.dir-locals hides /usr/share/emacs/24.3/lisp/gnus/.dir-locals
> 
> Features:
> (shadow emacsbug sendmail sort shr-color color qp shr mm-archive
> mail-extr gnus-async gnus-bcklg gnus-ml disp-table vc-git tmm nndraft
> nnmh nnfolder utf-7 gnutls network-stream starttls nnimap parse-time tls
> utf7 netrc gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
> gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig mailcap
> gnus-cache gnus-sum help-mode server gnus-demon nntp gnus-group
> gnus-undo nnmail mail-source gnus-start gnus-spec gnus-win nnoo gnus-int
> gnus-range message rfc822 mml mml-sec mm-decode mm-bodies mm-encode
> mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
> mailheader time-stamp windmove eldoc paredit slime-fancy
> slime-fontifying-fu slime-package-fu slime-references slime-scratch
> slime-presentations slime-fuzzy slime-fancy-trace slime-fancy-inspector
> slime-c-p-c slime-editing-commands slime-autodoc slime-parse slime-repl
> slime pp hyperspec thingatpt browse-url remember org-remember
> org-datetree org-jekyll org-publish org-exp ob-exp org-exp-blocks
> org-agenda org warnings ob-tangle ob-ref ob-lob ob-table org-footnote
> org-src ob-comint ob-keys org-pcomplete pcomplete comint ansi-color
> org-list org-faces org-entities noutline outline org-version
> ob-emacs-lisp ob org-compat org-macs ob-eval org-loaddefs format-spec
> find-func cal-menu calendar cal-loaddefs egg edmacro kmacro derived rx
> diff-mode easy-mmode ffap url-parse auth-source eieio byte-opt bytecomp
> byte-compile cconv password-cache url-vars electric egg-git egg-const
> egg-base ediff-merg ediff-diff ediff-wind ediff-help ediff-util
> ediff-mult ediff-init ediff egg-custom solarized-dark-theme
> solarized-definitions sr-speedbar advice help-fns advice-preload
> speedbar sb-image ezimage dframe cl-macs gv winner ring paren savehist
> msb gnus gnus-ems nnheader gnus-util mail-utils mm-util mail-prsvr
> wid-edit time cus-start cus-load cl cl-lib adjust-parens-autoloads
> egg-autoloads elisp-slime-nav-autoloads finder-inf git-gutter+-autoloads
> magit-autoloads magit-filenotify-autoloads package+-autoloads
> smtpmail-multi-autoloads sr-speedbar-autoloads w3m-autoloads info
> easymenu package time-date tooltip ediff-hook vc-hooks lisp-float-type
> mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe
> tabulated-list newcomment lisp-mode register page menu-bar rfn-eshadow
> timer select scroll-bar mouse jit-lock font-lock syntax facemenu
> font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
> thai tai-viet lao korean japanese hebrew greek romanian slovak czech
> european ethiopic indian cyrillic chinese case-table epa-hook
> jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
> cus-face macroexp files text-properties overlay sha1 md5 base64 format
> env code-pages mule custom widget hashtable-print-readable backquote
> make-network-process dbusbind dynamic-setting system-font-setting
> font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
> 
> -- 
> --
> regards,
> Samium Gromoff
> 
> 






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-16 20:53 ` Jan Djärv
@ 2013-09-17  6:19   ` Samium Gromoff
  2013-09-17  7:23     ` Eli Zaretskii
  0 siblings, 1 reply; 31+ messages in thread
From: Samium Gromoff @ 2013-09-17  6:19 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 15398

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

Jan Djärv <jan.h.d@swipnet.se> writes:
> 16 sep 2013 kl. 21:48 skrev Samium Gromoff <_deepfire@feelingofgreen.ru>:
>
>> Running Emacs from a Mate session screws redraw completely.
>
> Like how?  What is a Mate?  Provide screenshots if you can.  Are you running Wayland? I see wayland-client below.

Mate is the modern fork of Gnome 2.
No, I'm not running Wayland, this is a regular X session : -)

The list of component versions was motivated by doing a "ldd `which emacs`".

The screenshot:


[-- Attachment #2: emacs-gtk-redraw-bug.png --]
[-- Type: image/png, Size: 2875770 bytes --]

[-- Attachment #3: Type: text/plain, Size: 29 bytes --]


-- 
regards,
Samium Gromoff

^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  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
  0 siblings, 2 replies; 31+ messages in thread
From: Eli Zaretskii @ 2013-09-17  7:23 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: 15398

> From: Samium Gromoff <_deepfire@feelingofgreen.ru>
> Date: Tue, 17 Sep 2013 10:19:38 +0400
> Cc: 15398@debbugs.gnu.org
> 
> The screenshot:

The only thing I see here that's wrong is that the frame background
does not hide what's beneath it.  Everything else is normal -- Emacs
never draws beyond the right edge of each line, except a single
character cell (to have a place to put the cursor there).

Does your environment have some transparency setting or something?





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  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
  1 sibling, 0 replies; 31+ messages in thread
From: Jan Djärv @ 2013-09-17 18:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15398, Samium Gromoff

Hello.

17 sep 2013 kl. 09:23 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Samium Gromoff <_deepfire@feelingofgreen.ru>
>> Date: Tue, 17 Sep 2013 10:19:38 +0400
>> Cc: 15398@debbugs.gnu.org
>> 
>> The screenshot:
> 
> The only thing I see here that's wrong is that the frame background
> does not hide what's beneath it.  Everything else is normal -- Emacs
> never draws beyond the right edge of each line, except a single
> character cell (to have a place to put the cursor there).
> 
> Does your environment have some transparency setting or something?

It does look like some kind of compositing manager bug.  It can be due to the fact that Emacs mixes Gtk+ (i.e. cairo) and regular X drawing.  We can probably do some kind of workaround, but this is really not an Emacs bug.

	Jan D.






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-17  7:23     ` Eli Zaretskii
  2013-09-17 18:50       ` Jan Djärv
@ 2013-09-17 21:17       ` Samium Gromoff
  2013-09-18  6:27         ` Eli Zaretskii
  1 sibling, 1 reply; 31+ messages in thread
From: Samium Gromoff @ 2013-09-17 21:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15398

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Samium Gromoff <_deepfire@feelingofgreen.ru>
>> Date: Tue, 17 Sep 2013 10:19:38 +0400
>> Cc: 15398@debbugs.gnu.org
>> 
>> The screenshot:
>
> The only thing I see here that's wrong is that the frame background
> does not hide what's beneath it.

In fact, if I start scrolling the buffer, I start seeing text ghosts,
where character cells are not being cleared, as they should be.

[...]
> Does your environment have some transparency setting or something?

No, absolutely not.

I must add that Emacs if the only application affected by this strange bug.

-- 
regards,
Samium Gromoff





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-17 21:17       ` bug#15398: UNS: " Samium Gromoff
@ 2013-09-18  6:27         ` Eli Zaretskii
  2013-09-18 21:07           ` Samium Gromoff
  0 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2013-09-18  6:27 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: 15398

> From: Samium Gromoff <_deepfire@feelingofgreen.ru>
> Cc: jan.h.d@swipnet.se,  15398@debbugs.gnu.org
> Date: Wed, 18 Sep 2013 01:17:52 +0400
> 
> > The only thing I see here that's wrong is that the frame background
> > does not hide what's beneath it.
> 
> In fact, if I start scrolling the buffer, I start seeing text ghosts,
> where character cells are not being cleared, as they should be.

Can you show a screenshot of that?

> I must add that Emacs if the only application affected by this strange bug.

Thanks, but that in itself doesn't yet say anything.  Emacs's display
engine uses some unorthodox techniques, as Jan explained.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-18  6:27         ` Eli Zaretskii
@ 2013-09-18 21:07           ` Samium Gromoff
  2013-09-19  6:50             ` Eli Zaretskii
  0 siblings, 1 reply; 31+ messages in thread
From: Samium Gromoff @ 2013-09-18 21:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15398

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

Eli Zaretskii <eliz@gnu.org> writes:
>> > The only thing I see here that's wrong is that the frame background
>> > does not hide what's beneath it.
>> 
>> In fact, if I start scrolling the buffer, I start seeing text ghosts,
>> where character cells are not being cleared, as they should be.
>
> Can you show a screenshot of that?

Here it goes -- I was scrolling downwards into the file, so the text
was moving upwards -- and you can see the undisturbed top, while the
bottom is full of stale character cells:


[-- Attachment #2: Screenshot from 2013-09-19 01:02:47.png --]
[-- Type: image/png, Size: 2337415 bytes --]

[-- Attachment #3: Type: text/plain, Size: 29 bytes --]


-- 
regards,
Samium Gromoff

^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-18 21:07           ` Samium Gromoff
@ 2013-09-19  6:50             ` Eli Zaretskii
  2013-09-19  8:05               ` martin rudalics
  0 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2013-09-19  6:50 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: 15398

> From: Samium Gromoff <_deepfire@feelingofgreen.ru>
> Cc: jan.h.d@swipnet.se,  15398@debbugs.gnu.org
> Date: Thu, 19 Sep 2013 01:07:26 +0400
> 
> >> In fact, if I start scrolling the buffer, I start seeing text ghosts,
> >> where character cells are not being cleared, as they should be.
> >
> > Can you show a screenshot of that?
> 
> Here it goes -- I was scrolling downwards into the file, so the text
> was moving upwards -- and you can see the undisturbed top, while the
> bottom is full of stale character cells:

Looks like some of the X functions don't clear areas in the window.
(Jan, does this make sense?)

If you type "M-x redraw-display RET", do the ghost characters go away?





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19  6:50             ` Eli Zaretskii
@ 2013-09-19  8:05               ` martin rudalics
  2013-09-19  8:10                 ` Eli Zaretskii
  2013-09-19 14:04                 ` Stefan Monnier
  0 siblings, 2 replies; 31+ messages in thread
From: martin rudalics @ 2013-09-19  8:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15398, Samium Gromoff

 > Looks like some of the X functions don't clear areas in the window.
 > (Jan, does this make sense?)

FWIW I see something similar on Debian 7.0.0 with GTK 3.4.2: Menu texts
and tooltips don't disappear - they overlay the frame areas after the
newlines of buffers and stay there even when scrolling.

 > If you type "M-x redraw-display RET", do the ghost characters go away?

When I do M-x redraw RET they disappear.

martin





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19  8:05               ` martin rudalics
@ 2013-09-19  8:10                 ` Eli Zaretskii
  2013-09-19  8:27                   ` martin rudalics
  2013-09-19 14:04                 ` Stefan Monnier
  1 sibling, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2013-09-19  8:10 UTC (permalink / raw)
  To: martin rudalics; +Cc: 15398, _deepfire

> Date: Thu, 19 Sep 2013 10:05:04 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Samium Gromoff <_deepfire@feelingofgreen.ru>, 15398@debbugs.gnu.org
> 
> FWIW I see something similar on Debian 7.0.0 with GTK 3.4.2: Menu texts
> and tooltips don't disappear - they overlay the frame areas after the
> newlines of buffers and stay there even when scrolling.

Does this happen only with the current trunk, or also with Emacs 24.3?
If the former, it could be a redisplay bug introduced lately.  If the
latter, that's indeed something related to the window manager.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19  8:10                 ` Eli Zaretskii
@ 2013-09-19  8:27                   ` martin rudalics
  2013-09-19  8:53                     ` Eli Zaretskii
  0 siblings, 1 reply; 31+ messages in thread
From: martin rudalics @ 2013-09-19  8:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15398

> Does this happen only with the current trunk, or also with Emacs 24.3?
> If the former, it could be a redisplay bug introduced lately.  If the
> latter, that's indeed something related to the window manager.

What's the canonical way to get the Emacs 24.3 branch when I only
have trunk here?

martin






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19  8:27                   ` martin rudalics
@ 2013-09-19  8:53                     ` Eli Zaretskii
  2013-09-19  9:25                       ` martin rudalics
  0 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2013-09-19  8:53 UTC (permalink / raw)
  To: martin rudalics; +Cc: 15398

> Date: Thu, 19 Sep 2013 10:27:29 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 15398@debbugs.gnu.org
> 
> > Does this happen only with the current trunk, or also with Emacs 24.3?
> > If the former, it could be a redisplay bug introduced lately.  If the
> > latter, that's indeed something related to the window manager.
> 
> What's the canonical way to get the Emacs 24.3 branch when I only
> have trunk here?

I meant the released 24.3 version.  But since you asked: do this from
the parent of the trunk:

  $ bzr branch bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/emacs-24

You can also use bzr:/bzr.savannah.gnu.org/emacs/emacs-24 for
anonymous checkout, if you don't have bzr+ssh set up on that system.

The above assumes you have a shared repo in the parent directory of
trunk.  If you don't, then start with these commands in the trunk
directory:

  $ cd .. && bzr init-repo .
  $ bzr reconfigure --use-shared trunk

After that, do the "bzr branch" shown above.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19  8:53                     ` Eli Zaretskii
@ 2013-09-19  9:25                       ` martin rudalics
  2013-09-19  9:31                         ` Eli Zaretskii
  0 siblings, 1 reply; 31+ messages in thread
From: martin rudalics @ 2013-09-19  9:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15398

> I meant the released 24.3 version.  But since you asked: do this from
> the parent of the trunk:
> 
>   $ bzr branch bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/emacs-24
> 
> You can also use bzr:/bzr.savannah.gnu.org/emacs/emacs-24 for
> anonymous checkout, if you don't have bzr+ssh set up on that system.

Thanks.  Emacs 24.3 does _not_ exhibit the strange behavior.  So
the problem happens only with trunk.

If you want me to bisect, please tell me how.

martin






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19  9:25                       ` martin rudalics
@ 2013-09-19  9:31                         ` Eli Zaretskii
  2013-09-19 10:58                           ` martin rudalics
  0 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2013-09-19  9:31 UTC (permalink / raw)
  To: martin rudalics; +Cc: 15398

> Date: Thu, 19 Sep 2013 11:25:14 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 15398@debbugs.gnu.org
> 
> Thanks.  Emacs 24.3 does _not_ exhibit the strange behavior.  So
> the problem happens only with trunk.
> 
> If you want me to bisect, please tell me how.

With "bzr bisect", I'd suggest.  Or did you mean something else?





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19  9:31                         ` Eli Zaretskii
@ 2013-09-19 10:58                           ` martin rudalics
  2013-09-19 13:04                             ` Eli Zaretskii
  0 siblings, 1 reply; 31+ messages in thread
From: martin rudalics @ 2013-09-19 10:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15398

>> If you want me to bisect, please tell me how.
> 
> With "bzr bisect", I'd suggest.  Or did you mean something else?

No.  But

bzr bisect
bzr: ERROR: unknown command "bisect"


martin





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19 10:58                           ` martin rudalics
@ 2013-09-19 13:04                             ` Eli Zaretskii
  2013-09-19 14:03                               ` martin rudalics
  0 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2013-09-19 13:04 UTC (permalink / raw)
  To: martin rudalics; +Cc: 15398

> Date: Thu, 19 Sep 2013 12:58:32 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 15398@debbugs.gnu.org
> 
> bzr bisect
> bzr: ERROR: unknown command "bisect"

It's a plugin, you need to install it (as it evidently didn't come
with your distribution).





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19 13:04                             ` Eli Zaretskii
@ 2013-09-19 14:03                               ` martin rudalics
  2013-09-19 14:20                                 ` Eli Zaretskii
  2013-09-19 16:17                                 ` Glenn Morris
  0 siblings, 2 replies; 31+ messages in thread
From: martin rudalics @ 2013-09-19 14:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15398

> It's a plugin, you need to install it (as it evidently didn't come
> with your distribution).

It might help if someone told me how to do that.

Thanks, martin






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19  8:05               ` martin rudalics
  2013-09-19  8:10                 ` Eli Zaretskii
@ 2013-09-19 14:04                 ` Stefan Monnier
  2013-09-19 14:21                   ` martin rudalics
  2013-09-19 14:54                   ` Serge Kosyrev
  1 sibling, 2 replies; 31+ messages in thread
From: Stefan Monnier @ 2013-09-19 14:04 UTC (permalink / raw)
  To: martin rudalics; +Cc: 15398, Dmitry Antipov, Samium Gromoff

> FWIW I see something similar on Debian 7.0.0 with GTK 3.4.2: Menu texts
> and tooltips don't disappear - they overlay the frame areas after the
> newlines of buffers and stay there even when scrolling.

I think it's a very recent change.  Might be for example r114314
What happens if you undo this patch?  (quoted below)


        Stefan


=== modified file 'src/ChangeLog'
--- a/src/ChangeLog	2013-09-17 06:33:24 +0000
+++ b/src/ChangeLog	2013-09-17 06:57:30 +0000
@@ -5,6 +5,8 @@
 	(fn_g_type_init) [!WINDOWSNT]: Define only if Glib < 2.36.0.
 	* xsettings.c (init_gconf, init_gsettings): Do not check
 	for g_type_init.
+	* xterm.c (handle_one_xevent): Do not call to x_clear_area
+	if GTK >= 2.7.0.
 
 2013-09-16  Jan Djärv  <jan.h.d@swipnet.se>
 

=== modified file 'src/xterm.c'
--- a/src/xterm.c	2013-09-16 11:23:03 +0000
+++ b/src/xterm.c	2013-09-17 06:57:30 +0000
@@ -6151,7 +6151,7 @@
       f = x_window_to_frame (dpyinfo, event->xexpose.window);
       if (f)
         {
-#ifdef USE_GTK
+#if ! GTK_CHECK_VERSION (2, 7, 0)
           /* This seems to be needed for GTK 2.6.  */
 	  x_clear_area (event->xexpose.display,
 			event->xexpose.window,


[3. text/plain]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  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
  1 sibling, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2013-09-19 14:20 UTC (permalink / raw)
  To: martin rudalics; +Cc: 15398

> Date: Thu, 19 Sep 2013 16:03:24 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 15398@debbugs.gnu.org
> 
> > It's a plugin, you need to install it (as it evidently didn't come
> > with your distribution).
> 
> It might help if someone told me how to do that.

Download the code from here:

  https://code.launchpad.net/~bzr/bzr-bisect/trunk

(Just "bzr branch" from that URL.)

The way to install is described here:

  http://doc.bazaar.canonical.com/plugins/en/plugin-installation.html

You don't need the setup step in this case, just branching under
$HOME/.bazaar/plugins/ as explained in the above URL should be enough.





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19 14:04                 ` Stefan Monnier
@ 2013-09-19 14:21                   ` martin rudalics
  2013-09-19 14:54                   ` Serge Kosyrev
  1 sibling, 0 replies; 31+ messages in thread
From: martin rudalics @ 2013-09-19 14:21 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 15398, Dmitry Antipov, Samium Gromoff

> What happens if you undo this patch?  (quoted below)

Then everything is OK.

Thanks, martin






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19 14:20                                 ` Eli Zaretskii
@ 2013-09-19 14:24                                   ` martin rudalics
  0 siblings, 0 replies; 31+ messages in thread
From: martin rudalics @ 2013-09-19 14:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15398

> Download the code from here:
> 
>   https://code.launchpad.net/~bzr/bzr-bisect/trunk
> 
> (Just "bzr branch" from that URL.)
> 
> The way to install is described here:
> 
>   http://doc.bazaar.canonical.com/plugins/en/plugin-installation.html
> 
> You don't need the setup step in this case, just branching under
> $HOME/.bazaar/plugins/ as explained in the above URL should be enough.

Thanks, amrtin






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: 24.3; Frame redraw completely screwed
  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
  1 sibling, 1 reply; 31+ messages in thread
From: Serge Kosyrev @ 2013-09-19 14:54 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Dmitry Antipov, 15398, Samium Gromoff

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> FWIW I see something similar on Debian 7.0.0 with GTK 3.4.2: Menu texts
>> and tooltips don't disappear - they overlay the frame areas after the
>> newlines of buffers and stay there even when scrolling.
[...]
> I think it's a very recent change.  Might be for example r114314
> What happens if you undo this patch?  (quoted below)
> +#if ! GTK_CHECK_VERSION (2, 7, 0)
>            /* This seems to be needed for GTK 2.6.  */
>  	  x_clear_area (event->xexpose.display,
>  			event->xexpose.window,

Emacs (24.3) is linked to gtk3-3.8.4-1.fc19.x86_64 on my machine, indeed.

--
regards,
Samium Gromoff





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19 14:03                               ` martin rudalics
  2013-09-19 14:20                                 ` Eli Zaretskii
@ 2013-09-19 16:17                                 ` Glenn Morris
  2013-09-19 17:06                                   ` martin rudalics
  1 sibling, 1 reply; 31+ messages in thread
From: Glenn Morris @ 2013-09-19 16:17 UTC (permalink / raw)
  To: martin rudalics; +Cc: 15398

martin rudalics wrote:

>> It's a plugin, you need to install it (as it evidently didn't come
>> with your distribution).
>
> It might help if someone told me how to do that.

It's written in admin/notes/bzr





^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19 14:54                   ` Serge Kosyrev
@ 2013-09-19 16:41                     ` Jan Djärv
  2013-09-20  3:41                       ` Dmitry Antipov
  0 siblings, 1 reply; 31+ messages in thread
From: Jan Djärv @ 2013-09-19 16:41 UTC (permalink / raw)
  To: Serge Kosyrev; +Cc: 15398, Dmitry Antipov, Samium Gromoff

Hello.

19 sep 2013 kl. 16:54 skrev Serge Kosyrev <skosyrev@ptsecurity.ru>:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>>> FWIW I see something similar on Debian 7.0.0 with GTK 3.4.2: Menu texts
>>> and tooltips don't disappear - they overlay the frame areas after the
>>> newlines of buffers and stay there even when scrolling.
> [...]
>> I think it's a very recent change.  Might be for example r114314
>> What happens if you undo this patch?  (quoted below)
>> +#if ! GTK_CHECK_VERSION (2, 7, 0)
>>           /* This seems to be needed for GTK 2.6.  */
>> 	  x_clear_area (event->xexpose.display,
>> 			event->xexpose.window,
> 
> Emacs (24.3) is linked to gtk3-3.8.4-1.fc19.x86_64 on my machine, indeed.

I don't recall all the details, but I think the comment actually means "for GTK 2.6 and newer".

	Jan D.






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: UNS: Re: bug#15398: UNS: Re: bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19 16:17                                 ` Glenn Morris
@ 2013-09-19 17:06                                   ` martin rudalics
  0 siblings, 0 replies; 31+ messages in thread
From: martin rudalics @ 2013-09-19 17:06 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 15398

> It's written in admin/notes/bzr

Fine.  I wouldn't have searched in that directory.

Thanks, martin






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: 24.3; Frame redraw completely screwed
  2013-09-19 16:41                     ` Jan Djärv
@ 2013-09-20  3:41                       ` Dmitry Antipov
  2013-09-20  6:47                         ` Jan Djärv
  2020-09-09 13:24                         ` Lars Ingebrigtsen
  0 siblings, 2 replies; 31+ messages in thread
From: Dmitry Antipov @ 2013-09-20  3:41 UTC (permalink / raw)
  To: Jan Djärv, Serge Kosyrev; +Cc: 15398, Samium Gromoff

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).

Dmitry







^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: 24.3; Frame redraw completely screwed
  2013-09-20  3:41                       ` Dmitry Antipov
@ 2013-09-20  6:47                         ` Jan Djärv
  2013-09-20  8:00                           ` Dmitry Antipov
  2020-09-09 13:24                         ` Lars Ingebrigtsen
  1 sibling, 1 reply; 31+ messages in thread
From: Jan Djärv @ 2013-09-20  6:47 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 15398, Serge Kosyrev, Samium Gromoff

Hello.

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.  For this case, the widget thinks that nothing has been written to it (i.e. no Gtk+ methods have been called to do so), so the expose event does not need to redraw or clear anything.  But we have  written something, but with X calls, and the widget can't know this.

	Jan D.







^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: 24.3; Frame redraw completely screwed
  2013-09-20  6:47                         ` Jan Djärv
@ 2013-09-20  8:00                           ` Dmitry Antipov
  2013-09-20  9:32                             ` Jan Djärv
  0 siblings, 1 reply; 31+ messages in thread
From: Dmitry Antipov @ 2013-09-20  8:00 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 15398, Serge Kosyrev, Samium Gromoff

[-- 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:


^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: 24.3; Frame redraw completely screwed
  2013-09-20  8:00                           ` Dmitry Antipov
@ 2013-09-20  9:32                             ` Jan Djärv
  0 siblings, 0 replies; 31+ messages in thread
From: Jan Djärv @ 2013-09-20  9:32 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 15398, Serge Kosyrev, Samium Gromoff

Hello.

20 sep 2013 kl. 10:00 skrev Dmitry Antipov <dmantipov@yandex.ru>:

> 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
> 
> <gtk_clear_expose.patch>


This simply does not work.  It assumes there is only one frame per root window, which is wrong.
It assumes Emacs will get Unmap events when something obscuring it goes away, this is wrong (other applications may cover Emacs and the go away).

Any optimization attempt in this area is futile, it will lead to errors for a very small performance benefit.  The time is better spent into doing a proper double buffer solution.

	Jan D.






^ permalink raw reply	[flat|nested] 31+ messages in thread

* bug#15398: 24.3; Frame redraw completely screwed
  2013-09-20  3:41                       ` Dmitry Antipov
  2013-09-20  6:47                         ` Jan Djärv
@ 2020-09-09 13:24                         ` Lars Ingebrigtsen
  1 sibling, 0 replies; 31+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-09 13:24 UTC (permalink / raw)
  To: Dmitry Antipov
  Cc: 15398, Jan Djärv, Serge Kosyrev, Stefan Monnier,
	Samium Gromoff

Dmitry Antipov <dmantipov@yandex.ru> writes:

>> 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).

If I'm skimming this thread correctly, this revert fixed the reported
bug, so I'm closing this bug report.  If there's more to be done here,
please send a message to the debbugs address, and we'll reopen.

Jan Djärv <jan.h.d@swipnet.se> writes:

>> 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
>> 
>> <gtk_clear_expose.patch>
>
> This simply does not work.  It assumes there is only one frame per
> root window, which is wrong.
> It assumes Emacs will get Unmap events when something obscuring it
> goes away, this is wrong (other applications may cover Emacs and the
> go away).
>
> Any optimization attempt in this area is futile, it will lead to
> errors for a very small performance benefit.  The time is better spent
> into doing a proper double buffer solution.

And I think Emacs got that in the years that followed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2020-09-09 13:24 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2013-09-20  9:32                             ` Jan Djärv
2020-09-09 13:24                         ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).