GNU bug report logs - #16348
24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16348 in the body.
You can then email your comments to 16348 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Increasing internal-border-width cuts menubar and
 toolbar on non-toolkit builds
Date: Sun, 05 Jan 2014 14:34:09 +0900

[Message part 1 (text/plain, inline)]

Steps to reproduce:

1. Build emacs with --without-x-toolkit
2. $ emacs -Q &
3. (set-frame-parameter nil 'internal-border-width 10) C-j

Then menubar and toolbar look as if they were cut by the internal
border (see the attached screenshot).

(We can also see several other garbages in the internal border area,
but they had been there even on Emacs 24.3.)

This does not happen with Lucid or GTK+ builds.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

In GNU Emacs 24.3.50.1 (i386-apple-darwin13.0.0)
 of 2014-01-05 on YAMAMOTO-no-iMac.local
Bzr revision: 115871 eggert <at> cs.ucla.edu-20140105045623-d02sdbm8jiqeqs2v
Windowing system distributor `The X.Org Foundation', version 11.0.11404000
Configured using:
 `configure --without-x-toolkit --with-jpeg=no --with-gif=no
 --with-tiff=no CFLAGS=-g3'

[internal-border-cutting-bars.png (image/png, inline)]

Message #8 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50; Increasing internal-border-width cuts menubar
 and toolbar on	non-toolkit builds
Date: Sun, 05 Jan 2014 11:38:50 +0100

> Steps to reproduce:
>
> 1. Build emacs with --without-x-toolkit
> 2. $ emacs -Q &
> 3. (set-frame-parameter nil 'internal-border-width 10) C-j
>
> Then menubar and toolbar look as if they were cut by the internal
> border (see the attached screenshot).
>
> (We can also see several other garbages in the internal border area,
> but they had been there even on Emacs 24.3.)
>
> This does not happen with Lucid or GTK+ builds.

I can see this here as well.  There are many cases when redisplaying a
frame fails in this way, especially after setting a frame parameter.
Bug#14222 is another example.  When you maximize the frame and
subsequently restore its previous size the problems usually go away
(that's what I do in such cases).

What we needed here is some simple switch we can set and which causes
the redisplay engine to do a through redisplay instead of trying to be
clever and selectively clear/erase some space formerly occupied by a
scrollbar, fringe or border.

martin

Message #11 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50;
 Increasing internal-border-width cuts menubar and
 toolbar	on	non-toolkit builds
Date: Sun, 05 Jan 2014 18:37:44 +0200

> Date: Sun, 05 Jan 2014 11:38:50 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 16348 <at> debbugs.gnu.org
> 
> What we needed here is some simple switch we can set and which causes
> the redisplay engine to do a through redisplay instead of trying to be
> clever and selectively clear/erase some space formerly occupied by a
> scrollbar, fringe or border.

I believe what you want is to reset the enabled_p flag of each glyph
row in the current glyph matrix.  But since each window in a GUI
session has its own glyph matrix, you will need to do that for every
window on the current frame.

(Maybe there's a variable that has the same effect, I didn't check.)

Message #14 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50; Increasing internal-border-width cuts menubar
 and toolbar	on	non-toolkit builds
Date: Sun, 05 Jan 2014 17:48:59 +0100

>> What we needed here is some simple switch we can set and which causes
>> the redisplay engine to do a through redisplay instead of trying to be
>> clever and selectively clear/erase some space formerly occupied by a
>> scrollbar, fringe or border.
>
> I believe what you want is to reset the enabled_p flag of each glyph
> row in the current glyph matrix.  But since each window in a GUI
> session has its own glyph matrix, you will need to do that for every
> window on the current frame.
>
> (Maybe there's a variable that has the same effect, I didn't check.)

I'm not sure whether that would suffice.  Currently emacs does all sorts
of erasing and redrawing backgrounds of scrollbars, fringes, borders and
the like.  In many cases, it doesn't get that right.  The only practical
solution I usually see is to resize the frame to some other size and
size it back.  I doubt that this is the same as resetting the enabled_p
flags.

martin

Message #17 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50;
 Increasing internal-border-width cuts menubar and
 toolbar	on	non-toolkit builds
Date: Sun, 05 Jan 2014 19:07:30 +0200

> Date: Sun, 05 Jan 2014 17:48:59 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
> 
> The only practical solution I usually see is to resize the frame to
> some other size and size it back.  I doubt that this is the same as
> resetting the enabled_p flags.

What do you think it does, in addition?  It reallocates the glyph
matrices to fit the new dimensions, which clears that flag.

Anyway, I'm not aware of any mechanism in the display engine to avoid
redrawing portions of the screen, except the one that compares glyph
rows.  All the other redisplay optimizations are suppressed by setting
windows_or_buffers_changed, and I imagine you already do that.

If I'm wrong, can you point to the code that avoids redrawing those
parts?

Message #20 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50; Increasing internal-border-width cuts menubar
 and toolbar	on	non-toolkit builds
Date: Sun, 05 Jan 2014 18:59:29 +0100

>> The only practical solution I usually see is to resize the frame to
>> some other size and size it back.  I doubt that this is the same as
>> resetting the enabled_p flags.
>
> What do you think it does, in addition?  It reallocates the glyph
> matrices to fit the new dimensions, which clears that flag.
>
> Anyway, I'm not aware of any mechanism in the display engine to avoid
> redrawing portions of the screen, except the one that compares glyph
> rows.  All the other redisplay optimizations are suppressed by setting
> windows_or_buffers_changed, and I imagine you already do that.
>
> If I'm wrong, can you point to the code that avoids redrawing those
> parts?

If things were that easy I wouldn't have bothered you.  Take the
scenario from bug 14222:

(progn
  (set-frame-parameter (selected-frame) 'scroll-bar-width 6)
  (sit-for 1)
  (set-frame-parameter (selected-frame) 'left-fringe 27)
  (sit-for 1)
  (set-frame-parameter (selected-frame) 'scroll-bar-width 6)
  (sit-for 1))

I have inserted windows_or_buffers_changed settings all over
x_set_scroll_bar_width with no avail.  But when I subsequently re-resize
the frame, it gets drawn correctly.

martin

Message #23 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50;
 Increasing internal-border-width cuts menubar and
 toolbar	on	non-toolkit builds
Date: Sun, 05 Jan 2014 20:08:38 +0200

> Date: Sun, 05 Jan 2014 18:59:29 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
> 
>  >> The only practical solution I usually see is to resize the frame to
>  >> some other size and size it back.  I doubt that this is the same as
>  >> resetting the enabled_p flags.
>  >
>  > What do you think it does, in addition?  It reallocates the glyph
>  > matrices to fit the new dimensions, which clears that flag.
>  >
>  > Anyway, I'm not aware of any mechanism in the display engine to avoid
>  > redrawing portions of the screen, except the one that compares glyph
>  > rows.  All the other redisplay optimizations are suppressed by setting
>  > windows_or_buffers_changed, and I imagine you already do that.
>  >
>  > If I'm wrong, can you point to the code that avoids redrawing those
>  > parts?
> 
> If things were that easy I wouldn't have bothered you.  Take the
> scenario from bug 14222:
> 
> (progn
>    (set-frame-parameter (selected-frame) 'scroll-bar-width 6)
>    (sit-for 1)
>    (set-frame-parameter (selected-frame) 'left-fringe 27)
>    (sit-for 1)
>    (set-frame-parameter (selected-frame) 'scroll-bar-width 6)
>    (sit-for 1))
> 
> I have inserted windows_or_buffers_changed settings all over
> x_set_scroll_bar_width with no avail.  But when I subsequently re-resize
> the frame, it gets drawn correctly.

I meant if I'm wrong about disabling the current matrix's rows.

Message #26 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50; Increasing internal-border-width cuts menubar
 and toolbar	on	non-toolkit builds
Date: Sun, 05 Jan 2014 19:38:39 +0100

> I meant if I'm wrong about disabling the current matrix's rows.

You mean call clear_glyph_matrix for all windows?  Which matrices?

martin

Message #29 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50; Increasing internal-border-width cuts menubar
 and toolbar on	non-toolkit builds
Date: Sun, 05 Jan 2014 20:00:09 +0100

Hello.

martin rudalics skrev 2014-01-05 11:38:
> > Steps to reproduce:
> >
> > 1. Build emacs with --without-x-toolkit
> > 2. $ emacs -Q &
> > 3. (set-frame-parameter nil 'internal-border-width 10) C-j
> >
> > Then menubar and toolbar look as if they were cut by the internal
> > border (see the attached screenshot).
> >
> > (We can also see several other garbages in the internal border area,
> > but they had been there even on Emacs 24.3.)
> >
> > This does not happen with Lucid or GTK+ builds.
>
> I can see this here as well.  There are many cases when redisplaying a
> frame fails in this way, especially after setting a frame parameter.
> Bug#14222 is another example.  When you maximize the frame and
> subsequently restore its previous size the problems usually go away
> (that's what I do in such cases).
>
> What we needed here is some simple switch we can set and which causes
> the redisplay engine to do a through redisplay instead of trying to be
> clever and selectively clear/erase some space formerly occupied by a
> scrollbar, fringe or border

Does not SET_FRAME_GARBAGED do that?

    Jan D.

Message #32 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50;
 Increasing internal-border-width cuts menubar and
 toolbar	on	non-toolkit builds
Date: Sun, 05 Jan 2014 21:22:34 +0200

> Date: Sun, 05 Jan 2014 19:38:39 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
> 
>  > I meant if I'm wrong about disabling the current matrix's rows.
> 
> You mean call clear_glyph_matrix for all windows?

I guess so, for all windows on the frame.

> Which matrices?

The current ones, I think.

Message #35 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rudalics <at> gmx.at
Cc: 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50; Increasing internal-border-width cuts menubar
 and	toolbar	on	non-toolkit builds
Date: Sun, 05 Jan 2014 22:04:20 +0200

> Date: Sun, 05 Jan 2014 21:22:34 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 16348 <at> debbugs.gnu.org
> 
> > Date: Sun, 05 Jan 2014 19:38:39 +0100
> > From: martin rudalics <rudalics <at> gmx.at>
> > CC: mituharu <at> math.s.chiba-u.ac.jp, 16348 <at> debbugs.gnu.org
> > 
> >  > I meant if I'm wrong about disabling the current matrix's rows.
> > 
> > You mean call clear_glyph_matrix for all windows?
> 
> I guess so, for all windows on the frame.
> 
> > Which matrices?
> 
> The current ones, I think.

But the problem doesn't seem to be related to portions of the frame
not being redrawn in the test case you sent, i.e.:

  (progn
     (set-frame-parameter (selected-frame) 'scroll-bar-width 6)
     (sit-for 1)
     (set-frame-parameter (selected-frame) 'left-fringe 27)
     (sit-for 1)
     (set-frame-parameter (selected-frame) 'scroll-bar-width 6)
     (sit-for 1))

What seems to be happening here is that changing the left fringe to 27
pixels confuses Emacs about the dimensions of the text area, because
the right fringe disappears and the text area becomes wider than it
should be.

So I'm not sure the problem here is with redisplay optimizations at
all.

Message #38 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50; Increasing internal-border-width cuts menubar
 and toolbar on	non-toolkit builds
Date: Sat, 11 Jan 2014 11:24:21 +0100

> 1. Build emacs with --without-x-toolkit
> 2. $ emacs -Q &
> 3. (set-frame-parameter nil 'internal-border-width 10) C-j
> 
> Then menubar and toolbar look as if they were cut by the internal
> border (see the attached screenshot).

Should work now.  Please try again.

> (We can also see several other garbages in the internal border area,
> but they had been there even on Emacs 24.3.)

These should have been removed too.

> This does not happen with Lucid or GTK+ builds.

I think there was some garbage with the Lucid build as well.  The
Windows build certainly showed garbage too.  I tried to fix these
also.  Maybe something should be done for NS but I don't build it.

martin

Message #41 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50;
 Increasing internal-border-width cuts menubar and toolbar
 on	non-toolkit builds
Date: Sat, 11 Jan 2014 12:11:57 +0100

Hello.

11 jan 2014 kl. 11:24 skrev martin rudalics <rudalics <at> gmx.at>:

>> 1. Build emacs with --without-x-toolkit
>> 2. $ emacs -Q &
>> 3. (set-frame-parameter nil 'internal-border-width 10) C-j
>> Then menubar and toolbar look as if they were cut by the internal
>> border (see the attached screenshot).
> 
> Should work now.  Please try again.
> 
>> (We can also see several other garbages in the internal border area,
>> but they had been there even on Emacs 24.3.)
> 
> These should have been removed too.
> 
>> This does not happen with Lucid or GTK+ builds.
> 
> I think there was some garbage with the Lucid build as well.  The
> Windows build certainly showed garbage too.  I tried to fix these
> also.  Maybe something should be done for NS but I don't build it.

NS did not have the problem to begin with.

	Jan D.

Message #44 received at 16348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, 16348 <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50; Increasing internal-border-width cuts menubar
 and toolbar on	non-toolkit builds
Date: Sat, 11 Jan 2014 15:00:57 +0100

> NS did not have the problem to begin with.

OK.  Good to hear :-)

martin

Message #49 received at 16348-done <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: 16348-done <at> debbugs.gnu.org
Subject: Re: bug#16348: 24.3.50;
 Increasing internal-border-width cuts menubar and toolbar
 on	non-toolkit builds
Date: Mon, 13 Jan 2014 10:20:30 +0900

>>>>> On Sat, 11 Jan 2014 11:24:21 +0100, martin rudalics <rudalics <at> gmx.at> said:

>> 1. Build emacs with --without-x-toolkit
>> 2. $ emacs -Q &
>> 3. (set-frame-parameter nil 'internal-border-width 10) C-j
>> 
>> Then menubar and toolbar look as if they were cut by the internal
>> border (see the attached screenshot).

> Should work now.  Please try again.

I confirmed that it has been fixed on my side, too.  Thanks.
Closing.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.