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

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

[YAMAMOTO Mitsuharu]

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

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@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@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'

[-- Attachment #2: internal-border-cutting-bars.png --]
[-- Type: image/png, Size: 74448 bytes --]

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

[martin rudalics]

 > 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

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

[Eli Zaretskii]

> Date: Sun, 05 Jan 2014 11:38:50 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 16348@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.)

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

[martin rudalics]

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

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

[Eli Zaretskii]

> Date: Sun, 05 Jan 2014 17:48:59 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: mituharu@math.s.chiba-u.ac.jp, 16348@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?

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

[martin rudalics]

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

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

[Eli Zaretskii]

> Date: Sun, 05 Jan 2014 18:59:29 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: mituharu@math.s.chiba-u.ac.jp, 16348@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.

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

[martin rudalics]

 > 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

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

[Eli Zaretskii]

> Date: Sun, 05 Jan 2014 19:38:39 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: mituharu@math.s.chiba-u.ac.jp, 16348@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.

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

[Eli Zaretskii]

> Date: Sun, 05 Jan 2014 21:22:34 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 16348@debbugs.gnu.org
> 
> > Date: Sun, 05 Jan 2014 19:38:39 +0100
> > From: martin rudalics <rudalics@gmx.at>
> > CC: mituharu@math.s.chiba-u.ac.jp, 16348@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.

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

[Jan D.]

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.

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

[martin rudalics]

> 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

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

[Jan Djärv]

Hello.

11 jan 2014 kl. 11:24 skrev martin rudalics <rudalics@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.

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

[martin rudalics]

> NS did not have the problem to begin with.

OK.  Good to hear :-)

martin

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

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 11 Jan 2014 11:24:21 +0100, martin rudalics <rudalics@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@math.s.chiba-u.ac.jp