Lag on app switching (sometimes): is it expected?

[eugenesvk]

I've noticed that sometimes there is a noticeable slowdown on app switch with the script running (though it seems to happen once?). Think also noticed it a couple of times when reloading the script. Could it be related due to some injecting/caret detection logic or maybe defender or something? Is this expected to happen or might be an indication of some deeper issue? I have WindHawk Windows mod that's injecting itself in every process, maybe it could be an issue with the interaction between them, but can't force the lag, so not sure how to test properly

[yakunins]

@eugenesvk TY for report. I also have seen similar lag on first run.

1. Never seen lag happened twice with same instance of the script.
2. Never seen lag when script launched at startup.

Defender to blame? Maybe. The problem is that we have no reliable replication of the lag... Curious whether it's because of specific app running in foreground? Anyway, caret and cursor must be tested separately.

[eugenesvk]

I've tested a bit without the caret one (only mouse and tray) and don't get any lag, so definitely something is hanging in there. Maybe could check with disabling some of the detection methods to find out which one bugs... (though am worried it might be the most useful injection one...)

[PandaPYHNN]

I also met this issue.

From my view/test, looks like the getCaretPosFromWpfCaret spend some time and also fails. I add a debug print the GetCaretRect function;

LogF(val) {
	log_file := FileOpen("log.txt", "a")
	val := A_TickCount . ": " . val
	log_file.WriteLine(val)
	log_file.Close()
}

for fn in fns {
	LogF("Start fn: " . fn.Name)
	if fn() {
		cartetDetectMethod .= " (className:" . classname . ")"
		handleMaxInt(&left, &top, &right, &bottom)
		return true
	}
	LogF("End fn: " . fn.Name)
}

and got result of:

873658953: Start fn: getCaretPosFromUIA
873658953: End fn: getCaretPosFromUIA
873658953: Start fn: getCaretPosFromWpfCaret
873667203: End fn: getCaretPosFromWpfCaret   => takes 8250 ms
873667203: Start fn: getCaretPosFromHook
873667203: End fn: getCaretPosFromHook
873667218: Start fn: getCaretPosFromMSAA_2
873667328: Start fn: getCaretPosFromMSAA_2
873667437: Start fn: getCaretPosFromMSAA_2
873667546: Start fn: getCaretPosFromMSAA_2
873667656: Start fn: getCaretPosFromMSAA_2
873667765: Start fn: getCaretPosFromMSAA_2
873667875: Start fn: getCaretPosFromMSAA_2
873667984: Start fn: getCaretPosFromMSAA_2
873668093: Start fn: getCaretPosFromMSAA_2
873668203: Start fn: getCaretPosFromMSAA_2
873668312: Start fn: getCaretPosFromMSAA_2
873668312: End fn: getCaretPosFromMSAA_2
873668312: Start fn: getCaretPosFromUIA
873668312: End fn: getCaretPosFromUIA
873668312: Start fn: getCaretPosFromWpfCaret
873675984: End fn: getCaretPosFromWpfCaret   => takes 7672 ms
873675984: Start fn: getCaretPosFromHook
873675984: End fn: getCaretPosFromHook
873676031: Start fn: getCaretPosFromMSAA_2
873676062: Start fn: getCaretPosFromMSAA_2

Since I'm a starter of AHK, not quite know what happening in low layer. Hope this info helps.

[eugenesvk]

I've narrowed it down to ComCall(8, uia, "ptr*", focusedEle := ComValue(13, 0)) ; uia->GetFocusedElement(&focusedEle); within that function, so it's either UIA does some long enumeration to get to the focused element or maybe creating uia object takes long or maybe it's an error on missing object. I think once I got a rather slow response on shutting down a browser (though this doesn't explain why it normally lags when nothing is shut down)

But in general, that's something that I've noticed in all other caret detection ahk methods involving these UIAutomation frameworks - they can "randomly" stall...

[eugenesvk]

:) fellow happy travellers https://stackoverflow.com/questions/19631284/my-automationelement-findfirst-findall-seems-to-be-very-slow-how-to-improve-the

System.Windows.Automation is a lorry full of shit. I call AutomationElement.FindAll(TreeScope.Children, Condition.TrueCondition) and for returning a ridiculous amount of 30 children Microsoft's crappy code takes incredible 1000 ms on a very fast computer!! Additionally the whole crap is not even threadsafe! It is a shame how UIAutomation has been implemented. –