576182 - Avoid doing manual hit testing when the mouse is not in a known non-client area. (performance regression)

Status: RESOLVED INVALID

(Core :: Widget: Win32, defect)

Description

[Jim Mathies [:jimm]]

We get WM_NCHITTEST events for visible regions of the top level chrome window. There's no need to process or send hit testing events unless we know the mouse in in a possible drag area.

Comment 1

[Markus Stange [:mstange]]

(In reply to comment #0)
> We get WM_NCHITTEST events for visible regions of the top level chrome window.

When? Only on mousedown?

I don't think sending hit test events is expensive - it's the same workload as we're doing for every single mouse move event.

Comment 2

[Jim Mathies [:jimm]]

(In reply to comment #1)
> (In reply to comment #0)
> > We get WM_NCHITTEST events for visible regions of the top level chrome window.
> 
> When? Only on mousedown?
> 
> I don't think sending hit test events is expensive - it's the same workload as
> we're doing for every single mouse move event.

Any mouse event. Overhead for a hit test is added to existing mouse events for chrome currently. When 130078 lands this will expand to the entire window, including content. 

It should be easy to restrict this to the new client areas though so that in most areas we are "doing what we normally do".