Всем привет.

Решил я тут написать новые спецэффекты для своих кейгенов и столкнулся с такой проблемой:

Если запустить кейген после запуска винды, то графика работает медленно, как бы с тормозами.
Но! Стоит открыть какое-нибудь приложение (в частности, например Telegram Desktop), то графика в кейгене начинает работать, как задумано.
Такое ощущение, что сам трэд, отвечающий за отрисовку, работает на низком приоритете (смена приоритета не помогает).
Для обеспечения более-менее стабильного фпс использую связку QueryPerformanceCounter + WaitForSingleObject.
Проведённые замеры показывают, что до запуска Telegram Desktop цикл отрисовки работает в 2.5 раза медленнее.

Подскажите, пожалуйста, в какую сторону копать?

UPDATE:
Да, забыл, Win10, на Win7 всё ок

| Сообщение посчитали полезным:

Попробуй отключить галку Device Security > Memory Integrity, бывает решает проблемы с подвисанием и скоростью интерфейсофъ (но не факт что это ваш случай).

| Сообщение посчитали полезным:

Было выключено, да и не в нём дело 100%

| Сообщение посчитали полезным:

Любопытная история, но инфы маловато. Мб что-то из специфики софта\настроек ОС, дров видеокарты, или просто напросто баги кода, тут гадать остается (хотя может пользователи 10-ки и навскидку скажут "по опыту").
Можно из этой же оперы попробовать Exploit Protection > CFG > Off by Default > reboot
На некоторых десятках еще в WinForms GDI объекты текут, но опять же телега это "не залечит".

| Сообщение посчитали полезным:

VOLKOFF пишет:
просто напросто баги кода
Навряд ли. Не помню о чем конкретно шла речь (возможно о какой-то игре), там люди также сообщали, что запущенное приложение (WinAmp или какой-то проигрыватель) ускорял работу независимой проги. Но почему так происходило никто не написал.

Замечал за KMP непонятное поведение: если в фоне запущена какая-либо игра (или майнер), то в нем очень медленно отрисовываются менюшки (в других программах подобных тормозов не замечал), возможно, GDI по умолчанию задействует проц, но может работать и через видюху. Но это только мысли вслух сам подобным вопросом не занимался.

| Сообщение посчитали полезным: [X-Ray]

[X-Ray]
Это из области как включить GPU ускорение на классической теме винды))))

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

неплохо бы посмотреть код инициализации графики, и уже дальше думать что и как.

| Сообщение посчитали полезным:

Clockman, есть примеры кода какие-нибудь? Я гуглил на эту тему, но ничего подходящего не нашёл...

| Сообщение посчитали полезным:

[X-Ray] пишет:
есть примеры кода какие-нибудь?
C++ AMP, OpenCL, графические api (directx, opengl, vulkan, mantle...)

| Сообщение посчитали полезным:

ClockMan пишет:
Это из области как включить GPU ускорение на классической теме винды
Причаститься можно здесь:
https://exelab.ru/f/action=vthread&forum=12&topic=25612

| Сообщение посчитали полезным:

Приветствую! А ты эффекты в эбаут вынес. В отдельный диалог?

| Сообщение посчитали полезным:

Привет, Диджей. Нет, эффекты на главном окне. Эбаут у меня сейчас nfo viewer

Добавлено спустя 3 минуты
Скачал исходники ffmpeg, там вроде можно задействовать аппаратное ускорение. Буду курить их

Dezmand07, вулкан и директХ, конечно, здОрово, но тащить их в кейген считаю барством...

| Сообщение посчитали полезным:

телеграм как и другие приложения работающие с мультимедиа, например браузеры при проигрывании видео/аудио, изменяет частоту мультимедиа таймера, отсюда у тебя и ускорение.

| Сообщение посчитали полезным: [X-Ray], RamMerlabs, mak

Alchemistry, спасибо большое за здравый ответ! Пошел углубляться в тему

| Сообщение посчитали полезным:

в Вин10 эту фичу перенесли из сервиса в системный драйвер mmcss.sys и софты, которые могли ускоряться в Вин7, в десятке перестали

| Сообщение посчитали полезным:

Не знаю, применив timeBeginPeriod / timeEndPeriod я получил нужную производительность моего софта

| Сообщение посчитали полезным: ==DJ==[ZLO]

Я когда-то сталкивался с такими тормазами. Причем на мэйн диалоге если применял спецэффекты то норм. При выносе их в другое диалоговое окно получал тормоза. (я про --> Эффект водной поверхности <-- у ManHuntera видел --> ещё <-- сам не пробовал.

З.Ы.
Похвастайся эффектами

| Сообщение посчитали полезным: BlackCode

==DJ==[ZLO]
Реально, разговоров-то а что за спецэффекты, только догадывайся
[X-Ray]
Ролик запиши хоть, позырить

| Сообщение посчитали полезным:

Не смотря что обьекты гуя разные, у них общая обработка и синхронизации в ядре, а иногда даже через ipc. Сюда и нужно смотреть. А начать нужно со снятия профайла по сервисам, где оно начинает тормозить. Или в более простом случае как отличается активность апп при запуске другого. Как это сделать по простому я хз.

-----
vx

| Сообщение посчитали полезным:

Как просто и банально. Вот что бывает когда привык юзать базовый таймер, забываешь про "багофичи" любимой ОС

[X-Ray] пишет:
Пошел углубляться в тему
Думаю достаточно двух ссылок 1 и 2
В первой обрати внимание на последний коммент про WaitForSingleObject.

| Сообщение посчитали полезным:

VOLKOFF

По вашей первой ссылке ошибочная инфа от студента про дос. Планировщик нт изначально вызывался при завершении любого прерывания(обратный вызов хал, нотифи в кернел), для выравнивания тайминга планирования. Всё что там измеряется - выполняется на длительностях менее кванта, так что эти измерения не корректны. На таких длительностях нужен синхрон на многопотоке и замеры по прерываниям, сбросы SEG.RPL например. Впрочем как и такая простая нтапи как NtGetPerfCount далеко уже не простая, там пару десятков таймеров железных можно выбрать.

-----
vx

| Сообщение посчитали полезным:

--> Link <--

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

difexacaw пишет:
По вашей первой ссылке
Что вообще никак не снижает ценность обсуждения по ссылке для изучения вопроса по сабжу

Вообще, чтобы не заморачиваться этой возней с таймерами стоит учитывать несколько моментов:
1. Частота прерываний таймера зависит от HAL, а не от ядра и время выполнения потока определяется интервалами таймера, однако, система не пользуется подсчетом сигналов таймера для проверки продолжительности вы­полнения потока и истечения его кванта времени, учет времени выполнения потока основан на тактах процессора. Потоки на самом деле запускаются не на количество квантов времени, основанное на тактах системных часов, а на время, определенное квантовой целью, которая представляет собой приблизительный подсчет количества тактовых импульсов ЦП, потребленное потоком до того, как он уступит свою очередь другому потоку. В старых осях интервальный таймер использовался для истечения кванта времени, теперь у потоков тратятся не кванты, а тактовые циклы ЦП (и поправки уже нафег не нужны).
2. Когда окно выходит на первый план в клиентской системе, все потоки в процессе, содержащем тот поток, который владеет окном первого плана,получают утроенные кванты.
3. По умолчанию мультимедийные потоки получают 80% доступного времени ЦП (меняется в реестре) Поток планирования MMCSS выполняется с приоритетом 27, поскольку службе (опять же начиная с 7-ки висты, позднее это было запилено службой, но через драйвер MMCSS.sys вместо dll) нужно вытеснять любые потоки с целью снижения их приоритета до Exhausted.
4. Есть еще нюансы с IO и оптимизацией задержки для более чувствительных железок, новые фичи планировщика после Win8, особенности ARM, но это уже лирика... как и ностальгия по дос и "более зеленой траве".

| Сообщение посчитали полезным: GroundHog

В общем, если я правильно понял работу всего этого, то вот примерно такое получилось. Наверняка, избыточно,
но, тем не менее, работает

--> Link <--

BlackCode, ==DJ==[ZLO] --> Link <--

| Сообщение посчитали полезным: ==DJ==[ZLO]

[X-Ray] пишет:
но, тем не менее, работает
Ужос
timeBeginPeriod/timeEndPeriod это обертки для используемых сразу же перед ними функций.
При восстановлении в NtSetTimerResolution по канонам проще передавать вторым параметром 0 (тогда первый игнорится и должно восстановиться значение до предыдущего успешного вызова NtSetTimerResolution, иначе вернет STATUS_TIMER_RESOLUTION_NOT_SET)
Да и просто проверить не запросил ли кто-то уже частоту 1 или максимальную (<1) было бы логично, ведь тогда все ваши вызовы априори зафейлятся (система не даст увеличивать значения таймера, оно одно для всех, кто меньшее значение попросил, то и будет стоять, пока процесс сам не откажется, или не завершиться).
И само значение в НТ функцию передается не верное, оно должно быть в 100нс интервалах, те нужно еще нолик добавить
Это бы автоматически фиксилось, добавь вы очевидную проверку на выход запрашиваемого вами значения из диапазона минимального и максимального поддерживающегося в системе значения разрешения таймера (результат из NtQueryTimerResolution).

Alchemistry пишет:
например браузеры
Кстати хром на ноутах уже не жестит с этим (попинали в свое время за батарейку) и даже на десктопе без необходимости не уменьшает разрешение МТ. Про остальных не знаю.

| Сообщение посчитали полезным:

VOLKOFF

w10: KiDispatchInterrupt -> KiQuantumEnd(). Большая сложная функция, использующая кучи всяких счётчиков. TSC, TickCount, разные ранее вычисленные частоты(PerfGetCurrentFrequency etc). Хотелось бы посмотреть на реверснутую, как оно что там вычисляет. Но одно можно сказать что эти вычисления не связаны с прерываниями и таймерами. А если в реактос поискать ?

Видимо квантование основано на общей загрузке как системы, так и железа, но не на каких то абсолютных таймерах.

Добавлено спустя 13 минут
VOLKOFF

> Частота прерываний таймера зависит от HAL

Планировщик вызывается при обработке любого прерывания, я же говорил, какой есчо таймер. Так было всегда с w2k.

ps: можно исследовать прерывания в юм. Есть способ. Оно не нравилось очень аверам, когда профайл измеряют таким путём.

6f46_27.12.2019_EXELAB.rU.tgz - vt_swapctx_model.7z

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
какой есчо таймер
The frequency of the clock interrupts is up to the HAL, not the kernel©
Я приводил прямую цитату, поэтому все упреки в полном непонимании устройства Windows перенаправьте напрямую Руссиновичу

difexacaw пишет:
но не на каких то абсолютных таймерах
Там же написано как оно устроено (внезапно).

| Сообщение посчитали полезным:

VOLKOFF

Я больше дизу доверяю, чем какому то руссиновичу

Добавлено спустя 8 минут
VOLKOFF

Внезапно может для вас, эти два пиарщика марк и ионеску никаким образом не значатся в сурках нт. То что первый описывает как его научили, а второй наверно уже замучался отладочные символы ковырять не означает что они понимают и говорят правду.

-----
vx

| Сообщение посчитали полезным:

difexacaw ты же сам написал
difexacaw пишет:
Планировщик вызывается при обработке любого прерывания, я же говорил, какой есчо таймер.
Вопрос из зала - IRQ0 кто генерит?

| Сообщение посчитали полезным:

cppasm

APIC, кто же есчо. Вектора настраиваются. Какой вектор там весит я не помню, посмотри сам если нужно. В данном случае важно что все прерывания сходятся в одном вызове планировщика. А повышение точности таймеров врядле приведёт к повышению точности планирования, во первых не ясно как система распределяет время, а во вторых нт не реалтайм ос, там не важны часики и прочий желязячный синхрон. Задача ос распределить максимально эффективно время в зависимости от загрузки задач.

-----
vx

| Сообщение посчитали полезным: