21 Nov
2014
21 Nov
'14
1:26 p.m.
Hi!
On Fri, Nov 21, 2014 at 5:35 AM, Giannis Adamopoulos <
giannis.adamopoulos(a)reactos.org> wrote:
I don't know how many times I need to send the
same link here but let's
say that this is the last time:
this is a post about wpf but in the middle there is a paragraph about how
win32k in windows processes mouse messages:
http://blogs.msdn.com/b/dwayneneed/archive/2008/09/08/transparent-windows-i…
And here is the important part:
Which HWND is the mouse over?
The operating system must respond very quickly to mouse movement. Windows
uses a dedicated Raw Input Thread (RIT), running in the kernel, to handle
the signals from the mouse hardware. The RIT quickly scans over the HWND
hierarchy to see which window the mouse is over. Because the system must
be responsive, no application code is invoked. For normal windows, the RIT
checks the mouse position against the window's rectangle (or region, if one
is set). But for layered windows, the RIT looks in the bitmap that
specifies the content for the window and checks the effective transparency
at that location (which can be affected by the constant opacity setting,
the color key setting, or the per-pixel alpha channel). If the pixel is
100% transparent, the RIT skips the window and keeps looking. Once a
window has been located, the mouse move flag is set on the thread that owns
the window. This will cause the thread to receive a WM_MOUSEMOVE message
the next time it calls GetMessage() and there are no other higher-priority
messages.
Based on new wine test ReactOS is broken, and in the process of getting
fixed. Also
ReactOS breaks wine to dos in mouse over window while capture.
Now let me explain why a flag is needed. The window manager needs to
coalesce mouse move messages. If the mouse moves over a window and the
system registers 10 positions over it, if the window doesn't process
messages fast enough the unprocessed positions are dropped and only the
last is kept. Even if another message gets between these mouse move
messages get lost
I've seen more than 7 to one message lost during a fast mouse move.
More info here, https://jira.reactos.org/browse/CORE-8394 on what is going on.
That's why the last mouse position is not stored in a message queue but in
a field in the thread info. That's how the window
manager worked the last
20 years in windows.
Talking about,,,
/* 0b8 */ POINT ptLast;
in the threadinfo right? This can be fixed soon.
I'm sick and tired to see readable and correct code to be rewritten by
shitty code, that is not readable and has obvious bugs
without any reason
why the previous implementation was wrong. I just give up. Do whatever you
like with this shitty project of yours. I don't care anymore.
Days ago ReactOS had broken mouse move flag (always being set) and the QS
bit count
never reaching 0. Up X plus count then -1, always incrementing
and always set. Best way to fix all of this was r65440 (not pretty), our
posting mouse move messages to the queue is about the same as windows..
Synchronization of mouse messages should be fixed (CORE-8394
<https://jira.reactos.org/browse/CORE-8394>), no more erroneous mouse moves
injected while peeking in to see (no more stray bits set and wrong time
stamps). Using time stamps would be uglier than r65440.
Question now is, is it posted during peek or before (do this now), is that
what ptLast is for, how is it "time stamped", which would be faster post or
peek,, ?
This was my best guess on how to fix this, weeks of time, asked for group
review and even ran the patch through test bot about a week ago, all in all
this was one of the best rants, good ideas are flowing,
James