xterm.c (x_clear_frame) - commented out call to XClearWindow

xterm.c (x_clear_frame) - commented out call to XClearWindow

[Geoff Gole]

In x_clear_frame in in xterm.c, somebody has commented out a call to
XClearWindow:

  /* The following call is commented out because it does not seem to accomplish
     anything, apart from causing flickering during window resize.  */
  /* XClearWindow (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)); */

Unfortunately this results in a strip of pixels at the bottom of the
frame not being updated. You might be able to see it with:

  emacs -Q
  M-: (set-background-color "black")

Uncommenting the call fixes the problem, but results in the
aforementioned flicker during resize. Can we instead update only the
problematic strip:

  {
    int covered_pixels = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, FRAME_LINES (f));
    int leftover_pixels = FRAME_PIXEL_HEIGHT (f) - covered_pixels;

    XClearArea(FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
               0, FRAME_PIXEL_HEIGHT (f) - leftover_pixels,
               FRAME_PIXEL_WIDTH (f), leftover_pixels,
               0);
  }

Do I have this right? (I'm not familiar with either frame.c or xterm.c.)

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Chong Yidong]

Geoff Gole <geoffgole@gmail.com> writes:

> In x_clear_frame in in xterm.c, somebody has commented out a call to
> XClearWindow:
>
>   /* The following call is commented out because it does not seem to accomplish
>      anything, apart from causing flickering during window resize.  */
>   /* XClearWindow (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)); */
>
> Unfortunately this results in a strip of pixels at the bottom of the
> frame not being updated. You might be able to see it with:
>
>   emacs -Q
>   M-: (set-background-color "black")

I'm afraid I don't see any such strip on latest trunk,

  GNU Emacs 24.0.91.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0)

What system are you reporting this from?

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Geoff Gole]

>
> I'm afraid I don't see any such strip on latest trunk,
>

Hmm.

>  GNU Emacs 24.0.91.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0)
>
> What system are you reporting this from?
>

GNU Emacs 24.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12) of
2011-11-18. Let me know if other information would be helpful.

Let me amend my reproduction recipe a bit. I usually run emacs under a
tiling window manager which fullscreens everything by default, making
it easy to see the stale pixels. Under a more normal window manager I
have to do something like

  emacs -Q
  maximize the emacs
  M-: (set-background-color "red")

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Chong Yidong]

Geoff Gole <geoffgole@gmail.com> writes:

> Let me amend my reproduction recipe a bit. I usually run emacs under a
> tiling window manager which fullscreens everything by default, making
> it easy to see the stale pixels. Under a more normal window manager I
> have to do something like
>
>   emacs -Q
>   maximize the emacs
>   M-: (set-background-color "red")

OK, I see the problem now; thanks.  I guess your proposed fix is an OK
band-aid.  A more correct fix would be to make sure that the echo area
is painted properly when drawing glyph strings, i.e. all the way to the
bottom of the frame.  But that may not be a straightforward change.

The problem doesn't stop there, though: depending on the screen width,
there's a similar unpainted space to the right of the GTK scroll bar,
and another in the echo area where the scroll bar normally appears.

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Geoff Gole]

>
> OK, I see the problem now; thanks.  I guess your proposed fix is an OK
> band-aid.  A more correct fix would be to make sure that the echo area
> is painted properly when drawing glyph strings, i.e. all the way to the
> bottom of the frame.  But that may not be a straightforward change.
>
> The problem doesn't stop there, though: depending on the screen width,
> there's a similar unpainted space to the right of the GTK scroll bar,
> and another in the echo area where the scroll bar normally appears.
>

Indeed, I missed that. I also notice that there's no window covering
some of those areas, so mouse interaction is pretty broken there
(though unpainted space next to scroll bars inside the frame doesn't
have that problem).

It seems pretty broken to have leftover space there. It should
probably be part of the appropriate window.

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Jan Djärv]

Hello.

21 nov 2011 kl. 12:36 skrev Geoff Gole:

>> 
>> OK, I see the problem now; thanks.  I guess your proposed fix is an OK
>> band-aid.  A more correct fix would be to make sure that the echo area
>> is painted properly when drawing glyph strings, i.e. all the way to the
>> bottom of the frame.  But that may not be a straightforward change.
>> 
>> The problem doesn't stop there, though: depending on the screen width,
>> there's a similar unpainted space to the right of the GTK scroll bar,
>> and another in the echo area where the scroll bar normally appears.
>> 
> 
> Indeed, I missed that. I also notice that there's no window covering
> some of those areas, so mouse interaction is pretty broken there
> (though unpainted space next to scroll bars inside the frame doesn't
> have that problem).
> 
> It seems pretty broken to have leftover space there. It should
> probably be part of the appropriate window.


The uncommented XClearWindow in x_clear_frame must be there so I activated it again.

Just doing
(set-background-color "green")

and then

(set-background-color "white")

leaves big chunks of green where there is no text unless x_clear_frame does its job.
Flickering is almost unavoidable for Gtk as we bypass the normal Gtk drawing stuff.
Flickering also occurs for other toolkits, but not as bad.  The whole redraw mechanism used by Emacs is in it self flickerish.

	Jan D.

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Geoff Gole]

>
> The uncommented XClearWindow in x_clear_frame must be there so I activated it again.
>
> Just doing
> (set-background-color "green")
>
> and then
>
> (set-background-color "white")
>
> leaves big chunks of green where there is no text unless x_clear_frame does its job.

Hmm, I don't see that behaviour.

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Chong Yidong]

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

> The uncommented XClearWindow in x_clear_frame must be there so I
> activated it again...  Flickering is almost unavoidable for Gtk as we
> bypass the normal Gtk drawing stuff.

Obviously, I disagree.  AFAICT this has nothing to do with GTK.

The XClearWindow is obviously unnecessary if Emacs covers the entire
frame area when drawing glyph strings during redisplay, since the glyph
strings apply the background color.  The problem here arises because
there are some areas of the frame not drawn over durig redisplay,
e.g. the leftover spaces to the bottom and right in fullscreen mode.
The fact that these areas are unpainted may be regarded as a bug.  A
suitable temporary work-around would be to paint over them---but
painting the entire frame is clearly an overreach.

> Just doing
> (set-background-color "green")
>
> and then
>
> (set-background-color "white")
>
> leaves big chunks of green where there is no text unless x_clear_frame
> does its job.

I can't reproduce this at all.

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Jan Djärv]

22 nov 2011 kl. 06:31 skrev Chong Yidong:

> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> The uncommented XClearWindow in x_clear_frame must be there so I
>> activated it again...  Flickering is almost unavoidable for Gtk as we
>> bypass the normal Gtk drawing stuff.
> 
> Obviously, I disagree.  AFAICT this has nothing to do with GTK.

That depends on what you mean with "this".

> 
> The XClearWindow is obviously unnecessary if Emacs covers the entire
> frame area when drawing glyph strings during redisplay, since the glyph
> strings apply the background color.  The problem here arises because
> there are some areas of the frame not drawn over durig redisplay,
> e.g. the leftover spaces to the bottom and right in fullscreen mode.
> The fact that these areas are unpainted may be regarded as a bug.  A
> suitable temporary work-around would be to paint over them---but
> painting the entire frame is clearly an overreach.

It would be nice if we could just fix ther leftover spaces.  But I think it is too long in to pretest to fix this.  You have to first find all leftover spaces (i.e. under/between scroll bars, minibuffer, fringe) in all cases (font size not a multiple of frame size, fullscreen, and so on) and in all configurations (lucid, Gtk, just X, motif, with or without native scrollbars, with or without Xaw3d scrollbars).
And then for different environments, some redraw errors only appears with XFCE, some with Gnome-shell.

	Jan D.

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Stefan Monnier]

> It would be nice if we could just fix ther leftover spaces.  But I think it
> is too long in to pretest to fix this.  You have to first find all leftover

I think I agree, but I don't like just reverting without adding
a comment explaining the reason for this "redundant" call.


        Stefan

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Chong Yidong]

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

> It would be nice if we could just fix ther leftover spaces.  But I
> think it is too long in to pretest to fix this.  You have to first
> find all leftover spaces (i.e. under/between scroll bars, minibuffer,
> fringe) in all cases (font size not a multiple of frame size,
> fullscreen, and so on) and in all configurations (lucid, Gtk, just X,
> motif, with or without native scrollbars, with or without Xaw3d
> scrollbars).

AFAICT, we know where the extra spaces are: they're to the right of the
scroll bar, below the echo area, and to the right of the echo area.  It
shouldn't be difficult to clear precisely these three areas.

> And then for different environments, some redraw errors only appears
> with XFCE, some with Gnome-shell.

Any idea why?  I don't understand why the redisplay engine should behave
differently on different desktop environments.  If so, surely we'll have
bigger problems than merely unpainted frame areas.

Re: xterm.c (x_clear_frame) - commented out call to XClearWindow

[Jan Djärv]

23 nov 2011 kl. 07:09 skrev Chong Yidong:

> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> It would be nice if we could just fix ther leftover spaces.  But I
>> think it is too long in to pretest to fix this.  You have to first
>> find all leftover spaces (i.e. under/between scroll bars, minibuffer,
>> fringe) in all cases (font size not a multiple of frame size,
>> fullscreen, and so on) and in all configurations (lucid, Gtk, just X,
>> motif, with or without native scrollbars, with or without Xaw3d
>> scrollbars).
> 
> AFAICT, we know where the extra spaces are: they're to the right of the
> scroll bar, below the echo area, and to the right of the echo area.  It
> shouldn't be difficult to clear precisely these three areas.
> 
>> And then for different environments, some redraw errors only appears
>> with XFCE, some with Gnome-shell.
> 
> Any idea why?  I don't understand why the redisplay engine should behave
> differently on different desktop environments.  If so, surely we'll have
> bigger problems than merely unpainted frame areas.

I guess the difference is in Expose events, i.e. timings and order.  Some may be modified/generated by the window manager and/or the toolkit (i.e. Gtk+).

	Jan D.