Noticeable lag / delay when using Remote Desktop

[Brand-Wylie]

When I open Windows Terminal on Windows 10 in a Remote Desktop session there is noticeable input delay. Opening a separate PowerShell or CMD shell within the same environment performs normally.

[WSLUser]

It's not just when using Remote Desktop. Even in a VM given max resources possible (without causing insufficient resources for base OS), it's slow opening, especially since my default is PS Core and that takes awhile to load PS profile (in addition to WT profile).

[zadjii-msft]

Total spitball: maybe this is due to the Remote Desktop / VM connection trying to virtualize the DX rendering?

I'm really not sure though, it's hard to differentiate this from just #1064. I'm inclined to just close this as a dupe without more specific data for this scenario. We would definitely need some perf traces on this scenario specifically to see what the hot paths are here.

[WSLUser]

maybe this is due to the Remote Desktop / VM connection trying to virtualize the DX rendering?

I think that's exactly what's happening. However, equally possible as a result of that is that it fails and then performs software rendering instead. Not sure if there's a way to boost speed of software rendering to test but if possible, I'd add some library to deal with boosting software rendering speed to the project if the code can't be rewritten well enough to gain noticeable perf gains.

[WSLUser]

Make this ticket (or the other) about adding Boost: https://github.com/boostorg/boost to the project.

[zadjii-msft]

I mean I'm not sure how just "adding Boost" to the terminal would be a magic bullet to get a perf gain out of the Terminal - we'd need actual logs, traces, evidence of places in the code that are a bottleneck that would necessitate another library to solve the problem...

[j4james]

If the theory is that DX is to blame, you could probably confirm that by comparing the performance of a conhost session with and without the UseDx registry setting.

[DHowett-MSFT]

This seems like another version of /dup #1064, and #778 should help with it.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!