all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
@ 2014-01-05  5:34 YAMAMOTO Mitsuharu
  2014-01-05 10:38 ` martin rudalics
  2014-01-11 10:24 ` martin rudalics
  0 siblings, 2 replies; 15+ messages in thread
From: YAMAMOTO Mitsuharu @ 2014-01-05  5:34 UTC (permalink / raw)
  To: 16348

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

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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05  5:34 bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds YAMAMOTO Mitsuharu
@ 2014-01-05 10:38 ` martin rudalics
  2014-01-05 16:37   ` Eli Zaretskii
  2014-01-05 19:00   ` Jan D.
  2014-01-11 10:24 ` martin rudalics
  1 sibling, 2 replies; 15+ messages in thread
From: martin rudalics @ 2014-01-05 10:38 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: 16348

 > 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





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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05 10:38 ` martin rudalics
@ 2014-01-05 16:37   ` Eli Zaretskii
  2014-01-05 16:48     ` martin rudalics
  2014-01-05 19:00   ` Jan D.
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-01-05 16:37 UTC (permalink / raw)
  To: martin rudalics; +Cc: 16348

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






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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05 16:37   ` Eli Zaretskii
@ 2014-01-05 16:48     ` martin rudalics
  2014-01-05 17:07       ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: martin rudalics @ 2014-01-05 16:48 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 16348

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





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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05 16:48     ` martin rudalics
@ 2014-01-05 17:07       ` Eli Zaretskii
  2014-01-05 17:59         ` martin rudalics
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-01-05 17:07 UTC (permalink / raw)
  To: martin rudalics; +Cc: 16348

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





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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05 17:07       ` Eli Zaretskii
@ 2014-01-05 17:59         ` martin rudalics
  2014-01-05 18:08           ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: martin rudalics @ 2014-01-05 17:59 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 16348

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





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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05 17:59         ` martin rudalics
@ 2014-01-05 18:08           ` Eli Zaretskii
  2014-01-05 18:38             ` martin rudalics
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-01-05 18:08 UTC (permalink / raw)
  To: martin rudalics; +Cc: 16348

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





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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05 18:08           ` Eli Zaretskii
@ 2014-01-05 18:38             ` martin rudalics
  2014-01-05 19:22               ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: martin rudalics @ 2014-01-05 18:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 16348

 > 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





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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05 10:38 ` martin rudalics
  2014-01-05 16:37   ` Eli Zaretskii
@ 2014-01-05 19:00   ` Jan D.
  1 sibling, 0 replies; 15+ messages in thread
From: Jan D. @ 2014-01-05 19:00 UTC (permalink / raw)
  To: martin rudalics; +Cc: 16348

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.






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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05 18:38             ` martin rudalics
@ 2014-01-05 19:22               ` Eli Zaretskii
  2014-01-05 20:04                 ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-01-05 19:22 UTC (permalink / raw)
  To: martin rudalics; +Cc: 16348

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





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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05 19:22               ` Eli Zaretskii
@ 2014-01-05 20:04                 ` Eli Zaretskii
  0 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2014-01-05 20:04 UTC (permalink / raw)
  To: rudalics; +Cc: 16348

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





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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-05  5:34 bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds YAMAMOTO Mitsuharu
  2014-01-05 10:38 ` martin rudalics
@ 2014-01-11 10:24 ` martin rudalics
  2014-01-11 11:11   ` Jan Djärv
  2014-01-13  1:20   ` YAMAMOTO Mitsuharu
  1 sibling, 2 replies; 15+ messages in thread
From: martin rudalics @ 2014-01-11 10:24 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: 16348

> 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







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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-11 10:24 ` martin rudalics
@ 2014-01-11 11:11   ` Jan Djärv
  2014-01-11 14:00     ` martin rudalics
  2014-01-13  1:20   ` YAMAMOTO Mitsuharu
  1 sibling, 1 reply; 15+ messages in thread
From: Jan Djärv @ 2014-01-11 11:11 UTC (permalink / raw)
  To: martin rudalics; +Cc: 16348

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.







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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-11 11:11   ` Jan Djärv
@ 2014-01-11 14:00     ` martin rudalics
  0 siblings, 0 replies; 15+ messages in thread
From: martin rudalics @ 2014-01-11 14:00 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 16348

> NS did not have the problem to begin with.

OK.  Good to hear :-)

martin





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

* bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds
  2014-01-11 10:24 ` martin rudalics
  2014-01-11 11:11   ` Jan Djärv
@ 2014-01-13  1:20   ` YAMAMOTO Mitsuharu
  1 sibling, 0 replies; 15+ messages in thread
From: YAMAMOTO Mitsuharu @ 2014-01-13  1:20 UTC (permalink / raw)
  To: 16348-done

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





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

end of thread, other threads:[~2014-01-13  1:20 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-05  5:34 bug#16348: 24.3.50; Increasing internal-border-width cuts menubar and toolbar on non-toolkit builds YAMAMOTO Mitsuharu
2014-01-05 10:38 ` martin rudalics
2014-01-05 16:37   ` Eli Zaretskii
2014-01-05 16:48     ` martin rudalics
2014-01-05 17:07       ` Eli Zaretskii
2014-01-05 17:59         ` martin rudalics
2014-01-05 18:08           ` Eli Zaretskii
2014-01-05 18:38             ` martin rudalics
2014-01-05 19:22               ` Eli Zaretskii
2014-01-05 20:04                 ` Eli Zaretskii
2014-01-05 19:00   ` Jan D.
2014-01-11 10:24 ` martin rudalics
2014-01-11 11:11   ` Jan Djärv
2014-01-11 14:00     ` martin rudalics
2014-01-13  1:20   ` YAMAMOTO Mitsuharu

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.