bug#950: CVS Emacs on Windows XP fails to draw contents of new frame

bug#950: CVS Emacs on Windows XP fails to draw contents of new frame

[Francis Litterio]

CVS Emacs on Windows XP sometimes fails to draw the contents of a new
frame.  To reproduce, run "emacs -q", and evaluate this form:

    (let ((frame (make-frame)))
      (make-frame-invisible frame)
      (make-frame-visible frame))

The new frame's contents will not be drawn.  Typing "C-l" in the new
frame does not cause its contents to be drawn.  You have to switch focus
to another window and back again before the frame's contents are drawn.
--
Fran

bug#950: CVS Emacs on Windows XP fails to draw contents of new frame

[martin rudalics]

 > CVS Emacs on Windows XP sometimes fails to draw the contents of a new
 > frame.  To reproduce, run "emacs -q", and evaluate this form:
 >
 >     (let ((frame (make-frame)))
 >       (make-frame-invisible frame)
 >       (make-frame-visible frame))
 >
 > The new frame's contents will not be drawn.

Works here (on Windows XP).

 > Typing "C-l" in the new
 > frame does not cause its contents to be drawn.  You have to switch focus
 > to another window and back again before the frame's contents are drawn.

But the new frame is visible and in the foreground, I suppose.  What are
your focus-follows-mouse settings?

martin

bug#950: CVS Emacs on Windows XP fails to draw contents of new frame

[Juanma Barranquero]

>> The new frame's contents will not be drawn.
>
> Works here (on Windows XP).

I see the bug (Windows XP Home SP3).

It doesn't happen every time, though. I just did a few tests; in one,
the non-displaying behavior happened once, of twenty frames created.
In the very next run, it happened about one in three times.

   Juanma

bug#950: CVS Emacs on Windows XP fails to draw contents of new frame

[Francis Litterio]

martin rudalics wrote:

>> CVS Emacs on Windows XP sometimes fails to draw the contents of a new
>> frame.  To reproduce, run "emacs -q", and evaluate this form:
>>
>>     (let ((frame (make-frame)))
>>       (make-frame-invisible frame)
>>       (make-frame-visible frame))
>>
>> The new frame's contents will not be drawn.
>
> Works here (on Windows XP).
>
>> Typing "C-l" in the new
>> frame does not cause its contents to be drawn.  You have to switch focus
>> to another window and back again before the frame's contents are drawn.
>
> But the new frame is visible and in the foreground, I suppose.

Yes, it appears on top of the existing Emacs frame, but about 20 or 30
pixels to the right.

> What are
> your focus-follows-mouse settings?

focus-follows-mouse is nil.
--
Fran

bug#950: marked as done (CVS Emacs on Windows XP fails to draw contents of new frame)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]


Your message dated Sun, 15 Mar 2009 22:51:54 +0800
with message-id <49BD160A.6080106@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 CVS Emacs on Windows XP fails to draw contents of new frame
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 owner@emacsbugs.donarmstrong.com
immediately.)


-- 
950: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=950
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 2491 bytes --]

From: Francis Litterio <flitterio@gmail.com>
To: bug-gnu-emacs@gnu.org
Subject: CVS Emacs on Windows XP fails to draw contents of new frame
Date: Tue, 09 Sep 2008 12:51:22 -0400
Message-ID: <i5i6r67tut9t.fsf@gmail.com>

CVS Emacs on Windows XP sometimes fails to draw the contents of a new
frame.  To reproduce, run "emacs -q", and evaluate this form:

    (let ((frame (make-frame)))
      (make-frame-invisible frame)
      (make-frame-visible frame))

The new frame's contents will not be drawn.  Typing "C-l" in the new
frame does not cause its contents to be drawn.  You have to switch focus
to another window and back again before the frame's contents are drawn.
--
Fran




[-- Attachment #3: Type: message/rfc822, Size: 2993 bytes --]

From: Jason Rumney <jasonr@gnu.org>
To: 950-done@emacsbugs.donarmstrong.com
Subject: Re: bug#950: CVS Emacs on Windows XP fails to draw contents of new frame
Date: Sun, 15 Mar 2009 22:51:54 +0800
Message-ID: <49BD160A.6080106@gnu.org>

> 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.

bug#1748: 23.0.60; display of multiple frames: refresh and memory problems

[Drew Adams]

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'
 

bug#1748: marked as done (23.0.60; display of multiple frames: refresh and memory problems)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]


Your message dated Sun, 15 Mar 2009 22:51:54 +0800
with message-id <49BD160A.6080106@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 owner@emacsbugs.donarmstrong.com
immediately.)


-- 
950: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=950
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 5804 bytes --]

From: "Drew Adams" <drew.adams@oracle.com>
To: <emacs-pretest-bug@gnu.org>
Subject: 23.0.60; display of multiple frames: refresh and memory problems
Date: Tue, 30 Dec 2008 22:03:03 -0800
Message-ID: <006401c96b0d$7223b760$0200a8c0@us.oracle.com>

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'
 




[-- Attachment #3: Type: message/rfc822, Size: 2993 bytes --]

From: Jason Rumney <jasonr@gnu.org>
To: 950-done@emacsbugs.donarmstrong.com
Subject: Re: bug#950: CVS Emacs on Windows XP fails to draw contents of new frame
Date: Sun, 15 Mar 2009 22:51:54 +0800
Message-ID: <49BD160A.6080106@gnu.org>

> 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.

bug#2524: 23.0.91; Frame beneath the current one not fully redisplayed on w32

[Eli Zaretskii]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

  emacs -Q
  C-h n
  C-x 5 b RET
  C-h p
  C-x 1

After these keystrokes you should have 2 frames: one displaying NEWS,
the other one displaying the list of keywords for Emacs packages.

Now click and hold mouse on the foreground frame, and drag the frame
as fast as you can in circular movements against the background of the
second frame beneath it.  Eventually, you will see that the frame
beneath is not fully redisplayed in the portions that are exposed when
the foreground frame moves.  At that point, even if you stop dragging
the foreground frame and release the mouse, the frame beneath will not
be redisplayed.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
d:/gnu/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.0.91.1 (i386-mingw-nt5.1.2600)
 of 2009-02-28 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default-enable-multibyte-characters: t

Major mode: Outline

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  view-mode: t

Recent input:
C-h n C-x 5 b <return> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <find-emacs-packages> 
C-x 1 <help-echo> <help-echo> <help-echo> <switch-frame> 
<help-echo> <switch-frame> <switch-frame> <switch-frame> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <switch-frame> <switch-frame> <switch-frame> 
<help-echo> <switch-frame> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <switch-frame> 
<switch-frame> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <switch-frame> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<help-echo> <help-echo> <switch-frame> <help-echo> 
<help-echo> <help-echo> <switch-frame> <help-echo> 
<switch-frame> <help-echo> <help-echo> <help-echo> 
M-x r e p o r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading vc-cvs...done
View mode: type C-h for help, h for commands, q to quit.
SPC = select, <mouse-2> = select, d = to finder directory, q = quit, ? = help

bug#2524: 23.0.91; Frame beneath the current one not fully redisplayed on w32

[Drew Adams]

> Please write in English if possible, because the Emacs maintainers
> usually do not have translators to read other languages for them.
> 
> Your bug report will be posted to the 
> emacs-pretest-bug@gnu.org mailing list.
> 
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
> 
>   emacs -Q
>   C-h n
>   C-x 5 b RET
>   C-h p
>   C-x 1
> 
> After these keystrokes you should have 2 frames: one displaying NEWS,
> the other one displaying the list of keywords for Emacs packages.
> 
> Now click and hold mouse on the foreground frame, and drag the frame
> as fast as you can in circular movements against the background of the
> second frame beneath it.  Eventually, you will see that the frame
> beneath is not fully redisplayed in the portions that are exposed when
> the foreground frame moves.  At that point, even if you stop dragging
> the foreground frame and release the mouse, the frame beneath will not
> be redisplayed.
> 
> If Emacs crashed, and you have the Emacs process in the gdb debugger,
> please include the output from the following gdb commands:
>     `bt full' and `xbacktrace'.
> If you would like to further debug the crash, please read the file
> d:/gnu/emacs/etc/DEBUG for instructions.
> 
> 
> In GNU Emacs 23.0.91.1 (i386-mingw-nt5.1.2600)
>  of 2009-02-28 on HOME-C4E4A596F7
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4)'

Sounds to me like this is bug #1748 (which has gotten no reply), and which is
also part of bug #117 (part that remains unfixed). I'm surprised that no one
else has seen (or at least reported) it before now.

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1748

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=117

bug#2524: 23.0.91; Frame beneath the current one not fully redisplayed on w32

[Juanma Barranquero]

On Sun, Mar 1, 2009 at 22:50, Drew Adams <drew.adams@oracle.com> wrote:

> Sounds to me like this is bug #1748 (which has gotten no reply), and which is
> also part of bug #117 (part that remains unfixed).

BTW, could you please not conflate several things in the same bug report?

> I'm surprised that no one
> else has seen

Why do you think that?

> (or at least reported) it before now.

Why? It is already reported.

    Juanma

bug#2524: marked as done (23.0.91; Frame beneath the current one not fully redisplayed on w32)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]


Your message dated Sun, 15 Mar 2009 22:51:54 +0800
with message-id <49BD160A.6080106@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.91; Frame beneath the current one not fully redisplayed on w32
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 owner@emacsbugs.donarmstrong.com
immediately.)


-- 
950: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=950
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 6005 bytes --]

From: Eli Zaretskii <eliz@gnu.org>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.91; Frame beneath the current one not fully redisplayed on w32
Date: Sun, 01 Mar 2009 22:51:43 +0200
Message-ID: <uiqmtnezk.fsf@gnu.org>


Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

  emacs -Q
  C-h n
  C-x 5 b RET
  C-h p
  C-x 1

After these keystrokes you should have 2 frames: one displaying NEWS,
the other one displaying the list of keywords for Emacs packages.

Now click and hold mouse on the foreground frame, and drag the frame
as fast as you can in circular movements against the background of the
second frame beneath it.  Eventually, you will see that the frame
beneath is not fully redisplayed in the portions that are exposed when
the foreground frame moves.  At that point, even if you stop dragging
the foreground frame and release the mouse, the frame beneath will not
be redisplayed.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
d:/gnu/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.0.91.1 (i386-mingw-nt5.1.2600)
 of 2009-02-28 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default-enable-multibyte-characters: t

Major mode: Outline

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  view-mode: t

Recent input:
C-h n C-x 5 b <return> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <find-emacs-packages> 
C-x 1 <help-echo> <help-echo> <help-echo> <switch-frame> 
<help-echo> <switch-frame> <switch-frame> <switch-frame> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <switch-frame> <switch-frame> <switch-frame> 
<help-echo> <switch-frame> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <switch-frame> 
<switch-frame> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <switch-frame> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<help-echo> <help-echo> <switch-frame> <help-echo> 
<help-echo> <help-echo> <switch-frame> <help-echo> 
<switch-frame> <help-echo> <help-echo> <help-echo> 
M-x r e p o r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading vc-cvs...done
View mode: type C-h for help, h for commands, q to quit.
SPC = select, <mouse-2> = select, d = to finder directory, q = quit, ? = help




[-- Attachment #3: Type: message/rfc822, Size: 2993 bytes --]

From: Jason Rumney <jasonr@gnu.org>
To: 950-done@emacsbugs.donarmstrong.com
Subject: Re: bug#950: CVS Emacs on Windows XP fails to draw contents of new frame
Date: Sun, 15 Mar 2009 22:51:54 +0800
Message-ID: <49BD160A.6080106@gnu.org>

> 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.

bug#950: CVS Emacs on Windows XP fails to draw contents of new frame

[Francis Litterio]

CVS Emacs on Windows XP sometimes fails to draw the contents of a new
frame.  To reproduce, run "emacs -q", and evaluate this form:

    (let ((frame (make-frame)))
      (make-frame-invisible frame)
      (make-frame-visible frame))

The new frame's contents will not be drawn.  Typing "C-l" in the new
frame does not cause its contents to be drawn.  You have to switch focus
to another window and back again before the frame's contents are drawn.
--
Fran