EndPaint outside of lock for DxEngine

[miniksa]

The EndPaint command will naturally send all the queued drawing commands onto the underlying rendering target/bitmap/surface. Since all the data has already been captured and queued, there's no real sense in holding the lock on the I/O thread while the draw commands are performed. So this should probably move into the Present phase. But it will have to be reconciled with the invalid rectangle/scroll things that are usually done at EndPaint time.

[zadjii-msft]

🤔

Why did we never do this? This might have just sorted out like, a bunch of the miscellaneous deadlocks we're tracking (ala #12607)

[zadjii-msft]

@lhecker tell me why this wouldn't work:
https://github.com/microsoft/terminal/compare/dev/migrie/b/6523-endpaint-outside-lock?w=1

[lhecker]

D2D has an internal batch size limit for draw commands, so given enough text on the screen, it'll try to call D3D functions potentially many times before EndDraw is even called.
That said, it can't hurt to merge this. Reduces the chance for our issue even further...

[zadjii-msft]

Note to future self: this seemingly did not noticeably improve Terminal perf. Maybe it helps conhost perf, but I didn't have the cycles to further sanity check if this wouldn't just explode (esp. over RDP).

I'm closing this tab out now, see y'all in two more years when I reopen this 😜

[lhecker]

Oh, we do this now in AtlasEngine!