GNU bug report logs -
#950
CVS Emacs on Windows XP fails to draw contents of new frame
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sun, 15 Mar 2009 22:51:54 +0800
with message-id <49BD160A.6080106 <at> gnu.org>
and subject line Re: bug#950: CVS Emacs on Windows XP fails to draw contents of new frame
has caused the Emacs bug report #950,
regarding 23.0.60; display of multiple frames: refresh and memory problems
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact help-debbugs <at> gnu.org
immediately.)
--
950: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=950
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
I see this with my own setup, which uses more faces etc., but I
can reproduce it to some extent in emacs -Q. When many frames
are open, I see these problems, in order of severity, severity
worsening with more frames:
1. Redisplay problems. If a frame is partly behind another frame or
other window-mgr window, and the occluding frame is iconified or moved
out of the way, then the formerly hidden part of the occluded frame
that is now visible is not refreshed - it stays blanked out.
With enough frames it is never refreshed until I do `C-l'. The result
is that in practice, with my setup, having several frames means I must
often do `C-l' to see a frame.
2. Memory problems. With enough frames opened, I get a memory warning
from Emacs, or Emacs hangs altogether, or it crashes.
With my own setup, the redisplay problems happen with even a few frames,
the memory 75% warning appears with about 15 frames. And if I open, say 20
frames, Emacs hangs and I need to use the task manager to kill it - or it
crashes. With Emacs 20 through 22, I never see any such problems. I can have
several Emacses open at once, with any number of frames for each. As soon as I
use Emacs 23, I run into these problems.
With emacs -Q, it takes many, many more frames for problem #1 to appear, and I
have not yet seen problem #2. As I write this, I'm seeing the redisplay problem
somewhat in emacs -Q, with 30 frames open. But the problem is still slight in
emacs -Q: if I move a frame the others are redisplayed pretty quickly.
If I can isolate anything else in my own setup that contributes to this I'll
send it along, but that might not be soon or easy.
A quick way to test the redisplay problem with emacs -Q is to load dired-x.el,
set pop-up-frames to t, and eval this:
(defun dired-simultaneous-find-file (file-list option)
"Same as original, but respects `pop-up-frames'."
(let (size)
(cond ((and option (natnump option))
(while file-list (find-file-noselect (car file-list)) (pop
file-list)))
((or pop-up-frames option)
(while file-list (find-file-other-frame (car file-list)) (pop
file-list)))
(t
(setq size (/ (window-height) (length file-list)))
(when (> window-min-height size)
(error "Too many files to visit simultaneously. Try C-u prefix."))
(find-file (car file-list))
(pop file-list)
(while file-list
;; Vertically split off a window of desired size.
;; Upper window will have SIZE lines.
;; Select lower (larger) window. We split it again.
(select-window (split-window nil size))
(find-file (car file-list))
(pop file-list))))))
Then mark lots of files in Dired and hit `F' to open them all in
separate frames.
In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
of 2008-12-30 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
[Message part 3 (message/rfc822, inline)]
> CVS Emacs on Windows XP sometimes fails to draw the contents of a new
> frame.
This bug (also reported as bug#1748 and bug#2524) should be fixed now.
It was due to a poorly implemented redraw optimization within Windows,
which I have worked around by using a non-standard paint message
internally in Emacs.
This bug report was last modified 16 years and 125 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.