Redisplay problems; request for help

Redisplay problems; request for help

[Jim Blandy]

I've been seeing a problem with redisplay that I can't quite
reproduce; if someone else has a reliable method, I can try to debug
it.

When a window's start changes, either due to something like an
i-search moving to a match some distance down the buffer and redisplay
recentering the display, or due to IRC conversation rolling off the
bottom of the window, some areas of the screen that should be cleared
occasionally have text from the prior rendering left in them.  C-l
redraws things correctly, but as the incorrect characters are drawn
from (another part of) the same buffer being displayed, the corruption
is not always easy to detect.

Unfortunately, I haven't found a way to make this happen reliably.  If
you have seen this and know how to make it go, please let me know.

Re: Redisplay problems; request for help

[Maurizio Vitale]

"Jim Blandy" <jimb@red-bean.com> writes:

> I've been seeing a problem with redisplay that I can't quite
> reproduce; if someone else has a reliable method, I can try to debug
> it.
>
> When a window's start changes, either due to something like an
> i-search moving to a match some distance down the buffer and redisplay
> recentering the display, or due to IRC conversation rolling off the
> bottom of the window, some areas of the screen that should be cleared
> occasionally have text from the prior rendering left in them.  C-l
> redraws things correctly, but as the incorrect characters are drawn
> from (another part of) the same buffer being displayed, the corruption
> is not always easy to detect.
>
> Unfortunately, I haven't found a way to make this happen reliably.  If
> you have seen this and know how to make it go, please let me know.
>

Jim,
        it might be the same problem. Or not.
With CVS version of Emacs (including HEAD of this afternoon) I was
getting lot of redisplay problems. For me they happened in gnus, pretty
much all the times. When selecting articles (or typing C-x1 in the
summary window) part of the screen was not redrawn with the new info.
The problematic parts tended to be in the middle or lower part of the
screen. Sometimes after a short while (<1 sec) some small portions of
the wrong parts would be corrected. And C-l would help somewhat, but not
always fully.

So far maybe not too useful. But here what I discovered: if I disable
all desktop effect (the eyecandies in compiz) things seem to be just
fine. This is on:

Linux cuma 2.6.25.16-0.1-default #1 SMP 2008-08-21 00:34:25 +0200 x86_64 x86_64 x86_64 GNU/Linux

and the distribution is OpenSuse. The video card is an nvidia GeForce
6200 using the NVidia drivers for openGL acceleration.

OTH,

        Maurizio

Re: Redisplay problems; request for help

[Kenichi Handa]

In article <87wsh8i89j.fsf@cuma.polymath-solutions.lan>, Maurizio Vitale <mav@cuma.polymath-solutions.lan> writes:

> "Jim Blandy" <jimb@red-bean.com> writes:
> > I've been seeing a problem with redisplay that I can't quite
> > reproduce; if someone else has a reliable method, I can try to debug
> > it.
> >
> > When a window's start changes, either due to something like an
> > i-search moving to a match some distance down the buffer and redisplay
> > recentering the display, or due to IRC conversation rolling off the
> > bottom of the window, some areas of the screen that should be cleared
> > occasionally have text from the prior rendering left in them.  C-l
> > redraws things correctly, but as the incorrect characters are drawn
> > from (another part of) the same buffer being displayed, the corruption
> > is not always easy to detect.
[...]
>         it might be the same problem. Or not.
> With CVS version of Emacs (including HEAD of this afternoon) I was
> getting lot of redisplay problems. For me they happened in gnus, pretty
> much all the times. When selecting articles (or typing C-x1 in the
> summary window) part of the screen was not redrawn with the new info.
> The problematic parts tended to be in the middle or lower part of the
> screen. Sometimes after a short while (<1 sec) some small portions of
> the wrong parts would be corrected. And C-l would help somewhat, but not
> always fully.

> So far maybe not too useful. But here what I discovered: if I disable
> all desktop effect (the eyecandies in compiz) things seem to be just
> fine. This is on:

Do you see the same problem even if you turn off
auto-composition-mode globally?
  M-x global-auto-composition-mode RET

---
Kenichi Handa
handa@ni.aist.go.jp

Re: Redisplay problems; request for help

[Jim Blandy]

On Tue, Sep 23, 2008 at 10:54 PM, Kenichi Handa <handa@m17n.org> wrote:
> Do you see the same problem even if you turn off
> auto-composition-mode globally?
>  M-x global-auto-composition-mode RET

I'll give it a try.

Re: Redisplay problems; request for help

[Jim Blandy]

On Tue, Sep 23, 2008 at 10:54 PM, Kenichi Handa <handa@m17n.org> wrote:
> Do you see the same problem even if you turn off
> auto-composition-mode globally?
>  M-x global-auto-composition-mode RET

I assume you have a suspicion as to the cause of the problem.  If your
suspicions were correct, would they suggest something I could do to
make the problem occur reliably?

Re: Redisplay problems; request for help

[Kenichi Handa]

In article <8f2776cb0809240903r7fec07d5ue35fec8e59d2af56@mail.gmail.com>, "Jim Blandy" <jimb@red-bean.com> writes:

> On Tue, Sep 23, 2008 at 10:54 PM, Kenichi Handa <handa@m17n.org> wrote:
> > Do you see the same problem even if you turn off
> > auto-composition-mode globally?
> >  M-x global-auto-composition-mode RET

> I assume you have a suspicion as to the cause of the problem.  If your
> suspicions were correct, would they suggest something I could do to
> make the problem occur reliably?

My suspicious is just that some new code for handling
auto-composition-mode still has an unknown bug.  So, I can't
suggest you anything other than turning that mode off.

---
Kenichi Handa
handa@ni.aist.go.jp