inappropriate whole-frame flicker

inappropriate whole-frame flicker

[Miles Bader]

I noticed that when I do fairly innocuous things such as simply moving
the cursor around with C-n / C-p (without going past the window
boundaries, so it doesn't scroll), the text in the entire emacs frame
flickers; I guess it's redrawing the whole frame for each update!

I noticed this with my background-pixmaps branch, where such flicker
is a bit more obvious, but it also clearly happens with vanilla CVS
emacs.

For instance, just do:

  emacs -q

  `C-h n' to get the NEWS file.

  Move point around with C-n / C-p / C-f / C-b, being careful not to scroll.
 
  Watch the text flicker everywhere; even when the cursor is moving
  around, say, the top area of the window, the text on the bottom will
  flicker too.  Dragging the mouse-region around with the mouse is also
  a good way to get flicker (but that's a bit more drastic display-wise,
  so it's perhaps more defensible).

I gather that given the amount of redisplay optimization code in emacs,
this is not supposed to happen.  :-)

If no one has any idea, I'll go ahead and try to debug it, but any
pointers would be much appreciated.

Thanks,

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: inappropriate whole-frame flicker

[Miles Bader]

Miles Bader <miles@lsi.nec.co.jp> writes:
> I noticed that when I do fairly innocuous things such as simply moving
> the cursor around with C-n / C-p (without going past the window
> boundaries, so it doesn't scroll), the text in the entire emacs frame
> flickers; I guess it's redrawing the whole frame for each update!

BTW, I noticed that while this flicker is definitely happening on my
machine at work, my home machine doesn't show it!  Since my home
machine is slower, has a crappy video card, and runs an ancient version
of X, I don't think it's just less visible or anything.

The odd things is I'm using _exactly_ the same emacs source code for
both (basically CVS HEAD with a few probably-not-related tweaks), the
same configuration, and mostly the same OS (debian, but home is testing
and work is unstable).  I've done a `make clean; make' to flush out
bogons, and I'm using `emacs -q' to test it.  I'm completely confused as
to why it's happening.

[Fonts?  gcc version?  I'm running XFree86 3.x at home and 4.x at work,
so maybe the newer version somehow sending odd events or something...]

Unfortunately the machine that's displaying the problem is my work
machine, whereas my emacs debugging time is at home... :-(

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: inappropriate whole-frame flicker

[Richard Stallman]

    All the values stored in struct glyph are computed while producing
    glyphs, from buffer text, properties and so on.  Functions like
    x_append_glyph fill out a glyph structure with what was computed,
    usually from a struct it.  (I've factored the glyph filling in a few
    such functions; it's not distributed in the redisplay code.)  If some
    such function leaves some struct glyph member unset, which was the
    hard to find flicker case I've been mentioning in the #if 0'd code,
    there is a problem.

    When we leave glyphs unintialized the unset glyph member has a random
    value, which is clearly a bug.


    When we bzero glyphs, the unset field has a known value of zero, but
    that's a bug as well, because the computed value may well something
    different.

    So, whatever we do, the bug remains.

We could find these bugs systematically with debugging code that would
store unlikely values (analogous 0xdeadbeef) into all the fields, then
check later on which fields have the unlikely values.  There might be
some fields for which it is hard to find a suitable unlikely value,
but if this is possible for most fields, it would find most such bugs.

We could also use a macro SET_GLYPH_FIELD (fieldname, value) which
would normally set the field using the standard place to find the
glyph.  But when DEBUG, there would be two copies of the glyph, one
initialized to all 0s and one initialized to all 1s.  Then SET_GLYPH_FIELD
would set the specified field in both glyphs.  If the two
glyphs are not identical, some field was not set.

Would someone like to implement one of these ideas, so we can find 
such bugs easily?

Re: inappropriate whole-frame flicker

[Gerd Moellmann]

Richard Stallman <rms@gnu.org> writes:

> We could find these bugs systematically with debugging code

Another idea:

Forbid setting glyph members directly, for example, give the members
funny names that can be easily grepped for.

Then provide a procedural interface, an inline function or a macro,
with a parameter for each glyph member.  Then setting glyph members
would be an all or nothing operation.

Dunno how much work that is.

Re: inappropriate whole-frame flicker

[Miles Bader]

On Thu, Aug 28, 2003 at 12:53:06PM -0400, Richard Stallman wrote:
> We could also use a macro SET_GLYPH_FIELD (fieldname, value) which would
> normally set the field using the standard place to find the glyph.  But
> when DEBUG, there would be two copies of the glyph, one initialized to all
> 0s and one initialized to all 1s.  Then SET_GLYPH_FIELD would set the
> specified field in both glyphs.  If the two glyphs are not identical, some
> field was not set.

Please don't do this now (if ever).

That would uglify the code enormously, as well as causing many patching
conflicts for out-of-tree code involving redisplay.

Since the glyph stuff wasn't the cause of the problems I was seeing, there
doesn't seem to be any urgency to making this particular aspect of glyph
debugging easier.

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that
            will  make every christian in the world foamm at the mouth?
[iddt]      nurg, that's the goal