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)
- Fix bugs.
- Get paid!
If you solve that... :-)
Hi! tamlin@algonet.se wrote:
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)
Hum?~ I need to research this more.
- Fix bugs.
- Get paid!
If you solve that... :-)
LOL! Yeah~ James
Hi Mike! James Tabor wrote:
Hi! tamlin@algonet.se wrote:
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)
Hum?~ I need to research this more.
- Fix bugs.
- Get paid!
If you solve that... :-)
LOL! Yeah~ James
Okay,,, I was making a /. joke. Every list ends that way. Should end?
Now, There was a WM being called from both Kernel and User, ping ponging in and out. I can not remember which one it was.. With out any control point. I looked into Wine and they assume the application handles it, but that is not true. This is just one example.
LockWindowUpdate is a good idea. I'm still looking into it....
Thanks again, James