nanogui: Blocking mode operation for Microwindows/Win32 API
Subject:
RE: Blocking mode operation for Microwindows/Win32 API
From:
"KIM,KYOUNG-IL (HP-Cupertino,ex1)" ####@####.####
Date:
3 Jul 2001 22:20:37 -0000
Message-Id: <4341EF5F8B4AD311AB4B00902740B9F208952F80@xcup02.cup.hp.com>
Hi Greg,
Microwindows keeps polling even if VT_SWITCH=N.
Regardless of VT_SWITCH, uWin will set 10msec timer for select().
Regards,
Kyoung
-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Monday, July 02, 2001 11:36 PM
To: KIM,KYOUNG-IL (HP-Cupertino,ex1); ####@####.####
Cc: KIM,KYOUNG-IL (HP-Cupertino,ex1)
Subject: Re: Blocking mode operation for Microwindows/Win32 API
: Microwindow/Win32 API keeps polling for keypad and touch pad(mouse)
scanning
: and
: for peeking messages. This is not good for battery powered device like
PAD.
:
: I'm trying to change this polling mode operation to Blocking mode.
: To do this I modified select() of MwSelect()(in winmain.c) to blocking
mode.
: But it prevents for WM_PAINT(and more(?)) message from being processed
: because
: program stops at MwSelect() which is in the middle of PeekMessage() and
: PeekMessage()
: function won't be returned.
I have looked briefly into this. The Win32 API should not be polling
continuously when not processing PeekMessage. Yes, there is some
trick code that post-processes the WM_PAINT messages during
GetMessage(), but this should stop when there are no internal messages
to process, and select() hangs.
However, if you compile with VTSWITCH=Y, then Microwindows sets
up a timer that could be firing in order to process the VT switch requests.
I suggest recompiling Microwindows without this option and seeing whether
this behaviour continues. Let me know and I'll continue to look into this
bug.
Regards,
Greg
