Question: I know you said you tested this, but I'm still surprised. Is calling UWP Clipboard.GetContent() or DataPackageView.GetWhateverAsync() really that slow? I'd be a bit interested to see how you tested and measured this.

My memory is rusty but my belief is that UWP DataTransfer for clipboard shouldn't be a cross-process RPC call in all cases - just ones where the source data is hosted in an app that clipped it using the UWP or OLE clipboard APIs, forcing a cross-process COM call (IDataObject::Whatever()). (As opposed to when the source item came from the Win32 clipboard; in that case, UWP clipboard impl. in the destination should "just" do the win32k system call.)

I tested it using some code that I have already deleted. To make the new comparison as realistic as possible, I've chosen to implement the benchmark inside Windows Terminal itself and modified like so:

fire_and_forget TerminalPage::_PasteFromClipboardHandler(const IInspectable /*sender*/, const PasteFromClipboardEventArgs eventArgs)
try
{
    const auto beg = std::chrono::high_resolution_clock::now();
    winrt::hstring text;

    for (int i = 0; i < 1000; i++)
    {
        const auto data = Clipboard::GetContent();

        if (data.Contains(StandardDataFormats::Text()))
        {
            text = co_await data.GetTextAsync();
        }
        // Windows Explorer's "Copy address" menu item stores a StorageItem in the clipboard, and no text.
        else if (data.Contains(StandardDataFormats::StorageItems()))
        {
            auto items = co_await data.GetStorageItemsAsync();
            if (items.Size() > 0)
            {
                auto item = items.GetAt(0);
                text = item.Path();
            }
        }
    }

    const auto end = std::chrono::high_resolution_clock::now();
    const auto dur = std::chrono::duration<float, std::milli>(end - beg).count() / 1000.0f;
    wchar_t buffer[64];
    swprintf_s(buffer, L"%f\n", dur);
    OutputDebugStringW(&buffer[0]);

    // ... remaining contents of the function ...
}
CATCH_LOG();

Pasting text from X takes Y ms per iteration:

• Edge (Win32 clipboard API): 2.5ms
• Notepad: 3ms
• Explorer: 2.4ms
• The same instance of Windows Terminal (WinRT API): 2.1ms
• A different instance of Windows Terminal: also 2.1ms
• My bodgy clipboard code: 2.7ms

It seems there's no difference in latency for us between whether an application uses the WinRT or Win32 API for setting the clipboard contents. This made me curious whether the air got to my head once again and if I got everything, I said above wrong. So, I've tried to recreate my initial test code:

#define NOMINMAX
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>

// NOTE: This code relies on the latest cppwinrt version. To make matters simpler I've simply
// copy-pasted the winrt headers from terminal's "Generated Files" next to the current file.
#include "winrt/Windows.ApplicationModel.DataTransfer.h"
#include "winrt/Windows.Foundation.h"

int main() {
    winrt::init_apartment(winrt::apartment_type::single_threaded);

    []() -> winrt::fire_and_forget {
        const auto beg = std::chrono::high_resolution_clock::now();
        winrt::hstring text;

        for (int i = 0; i < 1000; i++) {
            const auto data = winrt::Windows::ApplicationModel::DataTransfer::Clipboard::GetContent();
            text = co_await data.GetTextAsync();
        }

        const auto end = std::chrono::high_resolution_clock::now();
        const auto dur = std::chrono::duration<float, std::milli>(end - beg).count() / 1000.0f;
        wprintf(L"%f\n", dur);
        PostQuitMessage(0);
    }();

    MSG msg;
    while (GetMessageW(&msg, nullptr, 0, 0)) {
        DispatchMessageW(&msg);
    }

    return 0;
}

Using it I get approximately the same latency as I get with Windows Terminal's code, which makes me believe that it's most likely correct, even if I can't immediately prove it. (If it's incorrect, please let me know!)

I did this because this allows me to run it in NVIDIA Nsight Systems to observe cross process behavior. Here's how it looks like when pasting from Edge into this application:

With that as an orientation, here's how one call (2.7ms) looks like:

You're right! There's no COM call in GetTextAsync when the clipboard content comes from Edge. GetContent however does involve 1 CoCreateInstance and 3 COM calls. I've blindly assumed that these are 1:1 directly related to the WinRT call that I'm doing. I'm genuinely sorry for this.

When the last instance of the CDataPackageView is destroyed it'll drop the CNonAgileOleRefTaker, which will end up calling OleUninitialize. This is probably not a good idea since this will also destroy the cached window it uses to call OpenClipboard. That's why every time you (or rather I, in my example project) call Clipboard::GetContent it'll recreate the window, which is very expensive overall (about half the entire CPU cost, the rest being mostly scheduling latency). Given that, I expect that the cost of the API would be significantly reduced if it wasn't calling OleUninitialize. And indeed, if I add a:

if (OleInitialize(nullptr) != S_OK) {
    abort();
}

to the start of my test application, the cost of getting the clipboard contents from Edge is consistently reduced down to about 1.8ms. It is however still in stark contrast to the Win32 API which takes roughly 0.0066ms on average on my system. I didn't run a ETW trace where the remaining cost lies. But if there's any more interest in this topic, I'd be happy to trace it.

I do realize that it could be argued that the Win32 API has an unfair advantage since it doesn't need to do any async thread switching, the way the COM code needs to do it. As such I've made the following test based on this branch:

fire_and_forget TerminalPage::_PasteFromClipboardHandler(const IInspectable /*sender*/, const PasteFromClipboardEventArgs eventArgs)
try
{
    const auto beg = std::chrono::high_resolution_clock::now();
    winrt::hstring text;

    for (int i = 0; i < 1000; i++) // <--- added
    {
        co_await winrt::resume_background(); // <--- added
        {
            // ... the win32 clipboard code from this PR ...
        }
        co_await wil::resume_foreground(Dispatcher()); // <--- added
    }

    const auto end = std::chrono::high_resolution_clock::now();
    const auto dur = std::chrono::duration<float, std::milli>(end - beg).count() / 1000.0f;
    wchar_t buffer[64];
    swprintf_s(buffer, L"%f\n", dur);
    OutputDebugStringW(&buffer[0]);

    // ... remaining contents of the function from this PR ...
}
CATCH_LOG();

This increases the cost to roughly 0.15ms per iteration on my system.
(We technically don't need to resume_foreground however so the actual cost is 0.013ms.)

Those benchmarks seem complete enough, I'll accept them, and you can close this thread out. :)

I raised this point because I don't like to see people go back to the win32 clipboard API from UWP clipboard API. Win32 clipboard is really much harder to use correctly; even in a simple case like this you had to build a OpenClipboard busy wait loop which isn't even guaranteed to succeed.

But clearly the speed up is significant enough that it's worth making this change.

Re the other discussion about ClipboardServer.dll - I might be wrong or out of date to say that it doesn't get used for basic clipboard functions. But my guess would be that its usage when you call UWP clipboard on desktop is for 1 of 2 reasons:

1. UWP app processes in a AppContainer use a broker to write to clipboard to filter out attempts to hijack higher-privileged processes with corrupt clipboard data. I thought that function wasn't built into ClipboardServer.dll, but maybe it is, or has become so. Within Windows Terminal, the UWP clipboard code in the caller process should be smart enough to see that it's not running from an AppContainer process and make the calls directly, but maybe it's not or there are other constraints.
2. On desktop, ClipboardServer is used to enforce clipboard enterprise data watermarking and restriction (Windows Information Protection/Enterprise Data Protection). This protection should apply to all clipboard APIs but I don't know how or when it's enforced for usage of each API.

I raised this point because I don't like to see people go back to the win32 clipboard API from UWP clipboard API. Win32 clipboard is really much harder to use correctly; even in a simple case like this you had to build a OpenClipboard busy wait loop which isn't even guaranteed to succeed.

Yeah, that's a totally fair point and I wouldn't mind sticking with the old code. In fact, the new API is honestly way nicer and easier to use. It's genuinely just not fast enough and I think this ever so slightly contributes to the growing computational inefficiency affecting Windows.

If there's an API that's a little bit harder to use, but multiple magnitudes more power efficient ¹, I think we not just should use it, but almost have a moral obligation to use it. Not just because we engineers are fickler when it comes to performance than product owners might hope ², but more importantly because the rising layers of abstraction and corresponding computational latency are unsustainable long-term. ³

In other words, I want Windows to be fast and power efficient, where everything you do is as good as it gets to the fullest extent of the underlying hardware and what we MS engineers are capable of delivering and it's what I'm trying to work towards.

I get that we should wait before trying again, but why are we doing 10*attempts here?

The usual approach is to do exponential backoffs: Every iteration you increase the backoff duration by like 2x for instance. I felt like doing just a linear backoff would work well enough for our primitive use case. After all, conhost uses the same API and doesn't use any retrying at all.

technically there's wil::unique_hglobal_locked, which takes an HGLOBAL and unlocks it later! On its own!