jimtabor wrote:
I noticed WndProc messages originate from win32k too.
The window
thread is
locked and then the message is sent out.
Example: Function call User32 -> Win32k -> send message.
Maybe we are doing double the work when we scroll on a bar. The rapid
blinking of the bar too. We maybe sending more than one message out.
Trying a hypothesis here, could it work if all such w32k-registered-
and-managed window classes, if not subclassed by the app, lock visual
updates while calling back into usermode (cmp. LockWindowUpdate(hWnd)
)?
(recursive calls, whether intentional or from buggy user-mode app code
could invalidate it)
4. Fix bugs.
5. Get paid!
If you solve that... :-)
--
Mike