>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
At 06:11 PM 8/23/99 +0900, Stephen J. Turnbull wrote:
> I still think that it wrong to leave the subwindow itself
> mapped; I have replaced the call to
> redisplay_unmap_subwindows_except_us() with a call to
> redisplay_unmap_subwindows() with no perceptible flickering
> (FWIW; this particular version of 2.1.19 did not show any
> flickering
Andy> Did it flicker without this change?
No. That platform (Gateway Solo 2000, C&T 65555, XF86_SVGA, Linux)
flickered in the very early implementation (at the time of Steve
Baur's first reports). Many things since then have changed, and I
have observed no flicker since the early fixes. Since no expose
events are generated while the glyph/subwindow is unmapped, that
should reduce flicker in this case as I understand the theory. I can
only say that on my platform it doesn't increase flicker, so it's
worth a try.
Andy> If it works for you then I'll put it in.
Hmm. I managed to get a lot of flicker with this build today, by
dragging one frame over another's tab control area. I also saw it
when I created a new frame with C-x 5 b and it happened (Window Maker
wm with RandomPlacement set) to partially obscure an existing frame's
tab control area. I couldn't reproduce with an xterm over XEmacs, but
that won't exercise XEmacs redisplay in the same way. It's
intermittent but common with XEmacs frame over frame.
Even when it doesn't flicker, the whole tab area disappears for a
perceptible time. Not good if it can be avoided.
Maybe it's not such a good idea. Window Maker is set to opaque drag,
though, and this produces a "poor man's bold" effect in the dragged
window, and a ripple of redisplay in the obscured one, it's such a
bandwidth hog (and those effects _always_ happen).
> If two frames are displaying buffers in the same mode, there
> are interactions between the buffer displayed in one and the
> list of tabs for the other, at least if the tab control is too
> wide for the second (no input via keyboard or mouse) frame.
> This seems to be associated with the other frame getting raised
> (I don't call that "input").
Andy> I don't understand.
Execute src/xemacs -q src/*{glyphs,redisplay}*.[ch] &
See that tabs are redisplay-msw.c and glyphs.h; buffers are redisplay.[ch]
Now C-x 1 to redisplay.h; C-x 5 b glyphs.h
Rearrange the frames to overlap:
------------------------------------------------------------------------
------------------------------------------------------------------------
Frame 2 tabs are redisplay-{output,msw}.c
Click frame 2 to redisplay-msw.c.
Frame 2 tabs are glyphs.h redisplay.h redisplay.c redisplay-x.c redisplay-tty.c
------------------------------------------------------------------------
------------------------------------------------------------------------
Raise frame 1 over frame 2, then raise frame 2.
Now frame 2 tabs are redisplay-{tty,output}.c
------------------------------------------------------------------------
------------------------------------------------------------------------
Perfectly reproducible, so I can't call it random. "Chaos", anyone?
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."