Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace WinRT clipboard API with Win32 for copying #17006

Merged
merged 2 commits into from
Apr 10, 2024

Conversation

lhecker
Copy link
Member

@lhecker lhecker commented Apr 3, 2024

In the spirit of #15360 this implements the copy part.
The problem is that we have an issue accessing the clipboard while
other applications continue to work just fine. The major difference
between us and the others is that we use the WinRT clipboard APIs.
So, the idea is that we just use the Win32 APIs instead.

The feel-good side-effect is that this is (no joke) 200-1000x faster,
but I suspect no one will notice the -3ms difference down to <0.01ms.

The objective effect however is that it just works.

This may resolve #16982.

Validation Steps Performed

  • Cycle through Text/HTML/RTF-only in the Interaction settings
  • Paste the contents into Word each time
  • Text is plain and HTML/RTF are colored ✅

@lhecker lhecker added Issue-Bug It either shouldn't be doing this or needs an investigation. Area-User Interface Issues pertaining to the user interface of the Console or Terminal Product-Terminal The new Windows Terminal. labels Apr 3, 2024
}

return wil::unique_close_clipboard_call{ success };
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a copy of the function from TerminalPage. My hope is that we resolve the duplicate at a future time and that the linker will fold it away until then.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, clipboard handling was kept outside of Control so that it could be customized by the owning app (e.g. visual studio putting it into local paste history or what-have-you). I am not against having copy behavior reside in the control, or in the UI-agnostic inner layers (however: clipboard IO requires an HWND…), but it is a significant departure from that goal.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Alas, the linker will not fold the copies away because they reside in different DLLs!)

Copy link
Member Author

@lhecker lhecker Apr 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we already support such usage of the API I'd be super happy to figure something out to make it work. However, if it was only a plan so far, we may IMHO be putting the cart before the horse: We can easily add clipboard customization at any time if needed, but we can't take it away. We should IMHO be as conservative as possible with exposing functionality via APIs as they will constrain our ability to quickly iterate on our code base and collapse unused/cumbersome functionality.
In this case not having it customizable makes the code simpler, but also more robust - even at the standard 120x9001 buffer size the HTML and RTF contents can easily be >40MB if the extra HSTRING conversions are used (3x overhead).

Clipboard::Flush();
}
CATCH_LOG();
}
Copy link
Member Author

@lhecker lhecker Apr 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Win32 APIs require the RTF/HTML contents to be ASCII/UTF8 which the TextBuffer already creates, but WinRT doesn't support. I really didn't want to have to convert such arbitrarily large strings from UTF8 > UTF16 > UTF8 in order to transmit them between classes. The conversion itself is not too slow, but the memory consumption for all that seemed concerning.
So I just moved the entire clipboard handling over into ControlCore.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WinRT doesn't support

FWIW, WinRT supports it just fine - using IBuffer and IBufferByteAccess

Copy link
Member

@carlos-zamora carlos-zamora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! Curious about the resolution to the API change discussion but I'm sure you two will figure it out.

Clipboard::Flush();
}
CATCH_LOG();
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WinRT doesn't support

FWIW, WinRT supports it just fine - using IBuffer and IBufferByteAccess

@DHowett DHowett added this pull request to the merge queue Apr 10, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Apr 10, 2024
@DHowett DHowett added this pull request to the merge queue Apr 10, 2024
Merged via the queue into main with commit 5f3a857 Apr 10, 2024
20 checks passed
@DHowett DHowett deleted the dev/lhecker/16982-win32-is-the-better-winrt branch April 10, 2024 20:07
DHowett pushed a commit that referenced this pull request Apr 22, 2024
In the spirit of #15360 this implements the copy part.
The problem is that we have an issue accessing the clipboard while
other applications continue to work just fine. The major difference
between us and the others is that we use the WinRT clipboard APIs.
So, the idea is that we just use the Win32 APIs instead.

The feel-good side-effect is that this is (no joke) 200-1000x faster,
but I suspect no one will notice the -3ms difference down to <0.01ms.

The objective effect however is that it just works.

This may resolve #16982.

* Cycle through Text/HTML/RTF-only in the Interaction settings
* Paste the contents into Word each time
* Text is plain and HTML/RTF are colored ✅

(cherry picked from commit 5f3a857)
Service-Card-Id: 92308708
Service-Version: 1.20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal.
Projects
Status: Rejected
Development

Successfully merging this pull request may close these issues.

can't copy and paste anything
3 participants