Мобильная версияВремя работы приложений Windows 11 становится неравномерным в «фоновом режиме» ⇐ C++
-
Anonymous
Время работы приложений Windows 11 становится неравномерным в «фоновом режиме»
У меня есть приложение для Windows, которое должно делать что-то каждые 40 миллисекунд (на самом деле его можно настроить на что угодно, но типичная настройка — 40 мс). У него достаточно времени для выполнения своих задач, поэтому большую часть этого времени он простаивает, но ему необходимо отправлять отчеты через определенные промежутки времени. Мы постоянно отслеживаем, занимает ли отчет в реальности больше или меньше 40 миллисекунд.
В Windows 7, 8 или 10 все работало хорошо. В Windows 11 возникла новая проблема: приложение работает хорошо только до тех пор, пока его окна не скрыты. Если его окна скрыты за развернутым окном другого приложения (Firefox, блокнот и т. д.), то через 5 секунд время становится неровным: превышение предельного срока в 40 мс, затем отставание для компенсации, затем снова превышение. , и так далее. Если вы вернетесь в окно нашего приложения с помощью Alt-Tab, вам придется подождать еще 5 секунд, но затем время снова станет плавным.
Это происходит только в том случае, если приложение находится за развернутым окном: если окна приложения скрыты за не-окном блокнота и где-то виден лишь небольшой кусочек пустого рабочего стола, то время остается гладким все время.
Похоже, что оконный менеджер Windows 11 принимает решение, основываясь на максимизации блокнота или чего-то еще, перевести наше приложение в своего рода «фоновый» режим. Что это за режим? Может ли мое приложение выполнить какой-нибудь вызов Windows API, чтобы предотвратить переход в этот режим?
Мы нашли один способ сделать это хуже: если мы зарегистрируем процесс с помощью SetCurrentProcessExplicitAppUserModelID(), то мы получим другое поведение: а именно, мы получим ровно 10 секунд » стоит хорошей производительности, то она становится плохой и остается плохой независимо от того, находимся ли мы на переднем плане или на заднем плане. Это может быть подсказкой, но я не уверен, в каком направлении она указывает, чтобы решить исходную проблему.
Если это актуально: наше приложение написано на C++, скомпилировано с помощью MSVC и использует Qt 6 для своих окон.
У меня есть приложение для Windows, которое должно делать что-то каждые 40 миллисекунд (на самом деле его можно настроить на что угодно, но типичная настройка — 40 мс). У него достаточно времени для выполнения своих задач, поэтому большую часть этого времени он простаивает, но ему необходимо отправлять отчеты через определенные промежутки времени. Мы постоянно отслеживаем, занимает ли отчет в реальности больше или меньше 40 миллисекунд.
В Windows 7, 8 или 10 все работало хорошо. В Windows 11 возникла новая проблема: приложение работает хорошо только до тех пор, пока его окна не скрыты. Если его окна скрыты за развернутым окном другого приложения (Firefox, блокнот и т. д.), то через 5 секунд время становится неровным: превышение предельного срока в 40 мс, затем отставание для компенсации, затем снова превышение. , и так далее. Если вы вернетесь в окно нашего приложения с помощью Alt-Tab, вам придется подождать еще 5 секунд, но затем время снова станет плавным.
Это происходит только в том случае, если приложение находится за развернутым окном: если окна приложения скрыты за не-окном блокнота и где-то виден лишь небольшой кусочек пустого рабочего стола, то время остается гладким все время.
Похоже, что оконный менеджер Windows 11 принимает решение, основываясь на максимизации блокнота или чего-то еще, перевести наше приложение в своего рода «фоновый» режим. Что это за режим? Может ли мое приложение выполнить какой-нибудь вызов Windows API, чтобы предотвратить переход в этот режим?
Мы нашли один способ сделать это хуже: если мы зарегистрируем процесс с помощью SetCurrentProcessExplicitAppUserModelID(), то мы получим другое поведение: а именно, мы получим ровно 10 секунд » стоит хорошей производительности, то она становится плохой и остается плохой независимо от того, находимся ли мы на переднем плане или на заднем плане. Это может быть подсказкой, но я не уверен, в каком направлении она указывает, чтобы решить исходную проблему.
Если это актуально: наше приложение написано на C++, скомпилировано с помощью MSVC и использует Qt 6 для своих окон.
