unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Bruno Félix Rezende Ribeiro" <oitofelix@gnu.org>
Cc: 18912@debbugs.gnu.org
Subject: bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display
Date: Mon, 03 Nov 2014 18:20:27 +0200	[thread overview]
Message-ID: <83ppd4w910.fsf@gnu.org> (raw)
In-Reply-To: <54571ABB.7020000@gnu.org>

> Date: Mon, 03 Nov 2014 04:03:39 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: rudalics@gmx.at, 18912@debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > Unnecessary redrawing causes unpleasant flickering that people
> > rightfully complain about.
> 
> It wouldn't be unnecessary because only people having a similar problem
> would deliberately enable the mode-line redrawing.  I can assure you a
> constantly corrupted mode-line is much more annoying than one fast flash
> that will only occur sporadically, in just one line, by direct command
> of the user.  In particular, on scroll operations all lines in the
> window are expected to change, so it's not that bad if just one more
> line, contiguous to the region, flashes.  Actually, the chances are that
> the flash won't be noticeable at all.

I'd like to solve this problem, not paper over it.  I hope you agree
that solving it is better than working around it.

> > Are you willing to debug this problem on your machine using GDB?  If
> > so, I might come up with some instructions.
> 
> Sure, why not?

Thanks, please find the instructions below.

> However, if we can't find the bug's root, I'll ask you to consider
> implementing the suggested workaround.  Deal? ;-)

I find it hard to believe that we won't find the root cause, so I
think we don't need to consider that possibility.

Here are the first instructions to get information that will help us
start digging into this.  (These are in addition to what Martin
already requested.)

First, please build Emacs without optimizations and with extra
checking code enabled:

  CFLAGS='-O0 -g3' ./configure --prefix=/home/felix/opt/emacs-24.4 --with-x-toolkit=athena --enable-checking='yes,glyphs'

(I only care about CFLAGS and the --enable-checking= option; the rest
I just copied from your original report, but feel free to change them
if you want.  The --enable-checking= option is required to compile the
dump-glyph-matrix command I ask you to use below.)

After 'configure' finishes, invoke "make".  You don't have to invoke
"make install", as Emacs can be run from the src/ directory where it
was built.

Now start Emacs you've just build with "emacs -Q", type the "C-x d"
command that you say is sufficient to reproduce the problem, and then
type this:

  M-x dump-glyph-matrix RET

This outputs to the standard error stream the description of the
internal data structure, called "glyph matrix", which Emacs maintains
for each window on a GUI frame.  Please post that output (you may wish
to redirect stderr to a file when you invoke Emacs, to make that
easier).

Please do this once for the "good" configuration, and another time for
the "bad" configuration, but please make sure you invoke Emacs the
same in both cases and type the same "C-x d" command in each case.

Next, in the "bad" configuration and with the listing of /dev and
corrupted mode line displayed, type this:

  M-: (setq frame-resize-pixelwise t) RET

Now carefully decrease the frame's height by dragging its upper or
lower edge with the mouse.  Please drag it slowly and carefully, so
that the frame is resized one pixel at a time.  After each resize,
please see if the mode line is no longer corrupted.  Perhaps kill the
buffer and type "C-x d" again to make sure the corruption disappeared
for good.  The first time the mode line stops being corrupted, type

  M-x dump-glyph-matrix RET

again, and include this (3rd) output in your message.  Also, please
tell how many pixels did you subtract from the original frame height
before the corruption disappeared (assuming it ever does).

Where are the instructions to use the debugger, you ask?  Well, not
yet, but maybe after we see what the above tells us.

Thanks.





  reply	other threads:[~2014-11-03 16:20 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-30 13:46 bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display Bruno Félix Rezende Ribeiro
2014-10-31 20:30 ` Stefan Monnier
2014-10-31 20:44   ` Bruno Félix Rezende Ribeiro
2014-11-01  8:42   ` Eli Zaretskii
2014-11-01 12:56     ` Bruno Félix Rezende Ribeiro
2014-11-01  8:38 ` Eli Zaretskii
2014-11-01  9:16   ` Eli Zaretskii
2014-11-01 12:54   ` Bruno Félix Rezende Ribeiro
2014-11-01 13:03     ` Eli Zaretskii
2014-11-02 21:49       ` Bruno Félix Rezende Ribeiro
2014-11-03  3:34         ` Eli Zaretskii
2014-11-03  6:03           ` Bruno Félix Rezende Ribeiro
2014-11-03 16:20             ` Eli Zaretskii [this message]
2014-11-03 17:43               ` martin rudalics
2014-11-03 17:52                 ` Eli Zaretskii
2014-11-03 18:01                   ` martin rudalics
2014-11-03 18:19                     ` Eli Zaretskii
2014-11-03 20:06               ` Bruno Félix Rezende Ribeiro
2014-11-03 20:24                 ` Eli Zaretskii
2014-11-03 20:29                   ` Eli Zaretskii
2014-11-03 20:46                     ` Eli Zaretskii
2014-11-03 21:01                       ` Bruno Félix Rezende Ribeiro
2014-11-03 21:19                         ` Eli Zaretskii
2014-11-04  6:05                           ` Bruno Félix Rezende Ribeiro
2014-11-04  8:25                             ` Bruno Félix Rezende Ribeiro
2014-11-04 16:00                               ` Eli Zaretskii
2014-11-04 19:24                                 ` martin rudalics
2014-11-04 19:52                                   ` Eli Zaretskii
2014-11-04 20:13                                 ` Stefan Monnier
2014-11-05  3:39                                   ` Eli Zaretskii
2014-11-05  9:17                                   ` Andreas Schwab
2014-11-04 21:09                                 ` Bruno Félix Rezende Ribeiro
2014-11-05 16:02                                   ` Eli Zaretskii
2014-11-05 21:38                                     ` Bruno Félix Rezende Ribeiro
2014-11-06  3:45                                       ` Eli Zaretskii
2014-11-06 15:28                                         ` Stefan Monnier
2014-11-04 15:54                             ` Stefan Monnier
2014-11-04 21:28                               ` Bruno Félix Rezende Ribeiro
2014-11-04 23:11                                 ` Stefan Monnier
2014-11-04 15:56                             ` Eli Zaretskii
2014-11-04 19:24                               ` martin rudalics
2014-11-04 20:55                                 ` Bruno Félix Rezende Ribeiro
2014-11-04 20:14                               ` Bruno Félix Rezende Ribeiro
2014-11-05  3:51                                 ` Eli Zaretskii
2014-11-05  6:28                                   ` Bruno Félix Rezende Ribeiro
2014-11-05 15:58                                     ` Eli Zaretskii
2014-11-05 19:46                                       ` Bruno Félix Rezende Ribeiro
2014-11-03 20:55                     ` Bruno Félix Rezende Ribeiro
2014-11-03 20:44                   ` Bruno Félix Rezende Ribeiro
2014-11-03  9:08           ` Andreas Schwab
2014-11-03 16:23             ` Eli Zaretskii
2014-11-03  9:41       ` martin rudalics
2014-11-03 18:58         ` Bruno Félix Rezende Ribeiro
2014-11-03 19:14           ` Eli Zaretskii
2014-11-03 20:10             ` Bruno Félix Rezende Ribeiro
2014-11-04  7:55           ` martin rudalics
2014-11-04  8:20             ` Bruno Félix Rezende Ribeiro
2014-11-04  9:19               ` martin rudalics
2014-11-04 10:25                 ` Bruno Félix Rezende Ribeiro
2014-11-04 16:16                   ` Eli Zaretskii
2014-11-04 19:56                     ` Bruno Félix Rezende Ribeiro
2014-11-04 19:23                   ` martin rudalics
2014-11-04 21:46                     ` Bruno Félix Rezende Ribeiro

Reply instructions:

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

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

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=83ppd4w910.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=18912@debbugs.gnu.org \
    --cc=oitofelix@gnu.org \
    /path/to/YOUR_REPLY

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

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