Capture OnFrame Callback very slow on Win11 23H2

[xuminjieleon]

Issue: Integrate capture into my electron app. when sharing some type of window (MS powerpoint, Word, folder, Chrome). onFrame callback very slow. the second event is ~10s+ later after the first event. And sometimes only 3 events in 2min.

Info: Before upgrade to Win11 23H2, the PC has no such issue. And only some Win11 23H2 PC have issue. Share screen is ok. Some windows are ok.

The core code is :

winrt::init_apartment();
m_controller = winrt::DispatcherQueueController::CreateOnDedicatedThread();
auto queue = m_controller.DispatcherQueue();

auto success = queue.TryEnqueue([this, &wc, &ready]() {
  Initialize();
});

Initialize() function do the similar thing as demo to create the capturer pool. and the onFrame callback , I just print log and get the frame without process like:

printlog();
auto frame = sender.TryGetNextFrame();
return;

Just response if you need more info.

[robmikh]

Are things changing on screen? There have been improvements recently to cut down on sending frames where there are no changes from the previous frame.

[xuminjieleon]

@robmikh Does there have any doc about this improvement? I will verify this with QA. Because I doubt this point at first, but I not find any release note about this improvement

[robmikh]

We don't have anything documenting this improvement at the moment.

I have heard something similar from another group, but it was in their automated tests where the screen wasn't updating frequently. Moving the mouse around or capturing an application that constantly presents a swap chain made the FrameArrived event fire more frequently. I would not be surprised if this is similar but let me know if not.

[xuminjieleon]

Verified. If the shared content changing, then have no issue.

[xuminjieleon]

btw, the improvment is quite bad.. at least callback 1 fps....

[robmikh]

We'll take that feedback into consideration, but eliminating unneeded rendering work has been a consistent request from our partners.

What's your scenario where maintaining a minimum capture rate is needed?

I'm closing this issue but feel free to add more information that we can take into consideration in the future.

[xuminjieleon]

I need know that capturer still alive and working. If you think callback too much, and waste memory, just give me the callback, with empty frame, or with specific error/return code. And most basiclly, it's really need to have a doc for such change, I search again and again in the existing MSDN.....

[xuminjieleon]

@robmikh do you know this "eliminating unneeded rendering work" start from which sprcific Windows version? Currently I can not see it on Win11 23H2 22631.3958 when trying the demo and print log with time on the frame callback

[robmikh]

There wasn't a single a change, it represents a series of improvements that span multiple versions of Win11.