Всем привет.

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

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

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

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

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

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

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

Кстати, о странном поведении GDI, вспомнил старый кейген от DI, с которого давным давно мы еще темплейт с эффектом переписывали/восстанавливали. Так вот

--> Красивейший кейген с обалденной музыкой <--

На XP работала бегущая строка, на системах новее (7+) уже нет... Так и не разобрались в чем дело



p.s. Сорри что немного не в тему) Наболело в свое время.

-----
ds

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

cppasm

> Так что говорить что таймер никак на планирование не влияет мягко говоря неправильно.

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

Есть несколько способов в юм что бы не писать драйвера для снятия профайла по квантованию и прерываниям. Проверь сам, сбрасывай селектор и измеряй число прерываний. Сделай на многопотоке, что бы исключить квантовые промежутки. Так же был способ прямо измерить длительность кванта. Вот этот метод. Я не упоминал, потому что он не сработает на старших версиях ос. Впрочем это врядле важно, не смотря на апдейт ядра механизмы планирований мало меняются из за обратной совместимости, поэтому метод до сих пор пригодится. А аверам это не нравится, так как это прямое измерение квантования реальной ос, в их вм этого нет в принципе, лишь фикс техники. А причём тут аверы - это всё техники из виксов, по обходу ав.

По основной задаче также сказал всё понятно, нужно провести замеры и узнать где садится профайл. Это угадать просто невозможно. Вопрос в том как это сделать наиболее просто.



51ca_29.12.2019_EXELAB.rU.tgz - vt_smsw_npx.pdf

-----
vx

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

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

difexacaw пишет:
По основной задаче
При неправильном использовании таймер может легко залипнуть (механизм изначально бажный) на 0.5мс (на современных железках) и создать немало рандомных тормозов, спасет только ребут системы.
Бросал бы топикстартер индусские наклонности и вообще не использовал этот "хак", он нужен для 100+ фпс, которые имхо ну никак не нужны в кейгене, даже при самом высоком разрешении мульти-таймера при хорошем коде можно выжать достаточные 60.

difexacaw пишет:
по квантованию и прерываниям
Поток может не израсходовать свой квант времени, в Windows запилен вытесняющий планировщик: когда готов поток с более высоким приоритетом, текущий поток может быть вытеснен еще до окончания его кванта времени. Фактически поток может быть вытеснен еще даже до начала своего кванта времени
Если при возникновении прерывания от интервального таймера количество затраченных тактовых циклов ЦП достигает квантовой цели (или превышает ее), запускается обработка истечения кванта.
Квант был сохранен внутри системы в виде доли такта таймера (точнее одной трети от такта интервального таймера), а не в виде целого такта, чтобы позволить частичный расход кванта на завершение ожидания в старых версиях Windows (до Vista). В предыдущих версиях интервальный таймер использовался для истечения кванта времени. Если бы не эта поправка, потоки могли бы иметь никогда не снижаемый квант времени. Повторюсь,- теперь у потоков тратятся не кванты, а тактовые циклы и поскольку этот процесс уже не зависит от интервального таймера, поправки теперь не нужны. И хватит навязывать подходы для антикварных ОС, их стоит иметь ввиду, но код писать ориентируясь на самое новое, так-то уже 2020 через пару дней, а вы все о прелестях W2k и W98

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

VOLKOFF пишет:
Бросал бы топикстартер индусские наклонности и вообще не использовал этот "хак", он нужен для 100+ фпс, которые имхо ну никак не нужны в кейгене, даже при самом высоком разрешении мульти-таймера при хорошем коде можно выжать достаточные 60.

так в том-то и дело, что мои замеры таймингов показывают требуемый фпс, но при этом всё как бы подтормаживает (только на Win10). Я на предыдущей странице ссылку давал на собранный темплейт с хаком и без, можете сами посмотреть

Добавлено спустя 2 минуты
хотяяяяяя, первый эффект у меня по задумке работает в 200 фпс

Добавлено спустя 6 минут
да, чот перебор, пожалуй, переделаю

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

VOLKOFF

> И хватит навязывать подходы для антикварных ОС, их стоит иметь ввиду, но код писать ориентируясь на самое новое

По мойму это вы про антиквар говорите, эти таймеры и IRQ были в дос и в первых версиях win. Нечего больше обсуждать, снимайте профайл. По нему затыка может быть и в юзер гуе. И в ядро лезть для данной задачи совсем незачем. Скорее всего другое апп останавливает какой то глобальный межпроцессный модуль, через который идёт активность гуя, например отменяет его оконный хук. Отсюда и повышение профайла, маловероятно что там более сложное.

-----
vx

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

@difexaclaw я за последние несколько дней прочитал кучу твоих заумных комментариев не по делу, из которых ничо непонятно) не пиши больше)

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

difexacaw пишет:
По мойму это вы про антиквар говорите
Все написанное мной выше актуальностью как минимум для Win10 14393, впрочем не думаю что за последние 2 года эти вещи как-то значимо изменили.

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

в общем, что я накопал:

Сделал замеры производительности графической части движка - может тянуть 150 фпс легко (возможно, даже больше);
тормоза же связаны с неточной работой WaitForSingleObject (Sleep тоже), который на моих замерах мог спать до 8 мс дольше положенного (вот же ж сволота). Просто на тех эффектах, где плавность не важна, это не было заметно, а сейчас выявилось...
Если ставить частоту вручную (NtSetTimerResolution), то тайминги приходят в норму и фпс четкий и стабильный...

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

[X-Ray]

А как же ты додумался вставить цикл ожидания/сна в тяжёлую графическую функцию

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

-----
vx

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

difexacaw пишет:
цикл ожидания/сна в тяжёлую графическую функцию
Господи, что за бред ты несешь опять
Про ограничение и стабилизацию фпс не слышал? Конечно кому это надо, пусть жрет как можно больше, может выжать 1000 раз за секнду, пусть отъедает 25% от проца, зато не вызываем слип

-----
В облачке многоточия

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

Boostyq

Он в функцию отрисовки вставил апи ожидания. По этой причине повышение числа прерываний приводит к меньшим тормозам. Так как из ожидания происходит более быстрый возврат вероятно(планировщик вызывается более часто). А девочкам в этих темах по мойму делать нечего.

-----
vx

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

difexacaw пишет:
Он в функцию отрисовки вставил апи ожидания

она там изначально была


difexacaw пишет:
Покури чтоле
ты, походу, уже покурил

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

[X-Ray]

Про многопоток слышал и синхронизации ?
Школота добралась до компилера. Гуй принимает сообщения их фильтрует и отправляет далее в систему, при этом не допустимо ожидание. Ты можешь этим повесить всю ось. --> Link <--

-----
vx

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

Модераторы, пропишите ему успокоительное, пожалуйста

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

[X-Ray] пишет:
Модераторы, пропишите ему успокоительное, пожалуйста
Дорогой зачем так говоришь? лучше докажи ему при всех где и почему он не прав.
Он дядька очень умный профессионал вы зря так.

Добавлено спустя 17 минут
DimitarSerg а что там за музыка размер дампа 70-80мб и всё размазано
куда они модуль запихнули?

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

[X-Ray]

Модеры тебе его пропишут не сомневаюсь прочитав эту тему. Мне нет за что, я описал всё нормально.

-----
vx

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

SDK пишет:
почему он не прав.

difexacaw пишет:
Школота

Каждый, кто с точки зрения спеца профан, имеет некоторые другие достоинства! Обратное не докажешь. Бывают исключения, но как говорят, исключение только подтверждает правило!

-----
IZ.RU

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

DenCoder

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

-----
vx

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

difexacaw пишет:
Он считает всё обсуждение выше бредом, потому что не понимает ничего
Ему нужно решение проще. Ты, Инди, очень сложно всё объясняешь )

-----
IZ.RU

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

DenCoder

Удалить из гуй-фильтра функцию ожидания, очевидно ведь и идти курить матчасть по написанию окон.

-----
vx

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

Крекл, где ты цикл ожидания в основном потоке нашел?

-----
2 оттенка серого

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

f13nd

Тут --> Link <--

Вот:
> Сделал замеры производительности графической части движка - может тянуть 150 фпс легко (возможно, даже больше);
> тормоза же связаны с неточной работой WaitForSingleObject

По мойму задача решена. Если тс чем то недоволен, то это его трудности он знал куда пришёл.

-----
vx

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

difexacaw пишет:
Тут
Ты методом кашпировского анализируешь, по постам? В основном потоке приложения нету ни WaitForSingleObject, ни Sleep. Со своими догадками по поводу PeekMessage с рендерером в основном цикле споришь чтоли? Нету там ничего такого.

-----
2 оттенка серого

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

f13nd

А с чего ты взял что нет ожидания в оконной процедуре, может он тебе свой код показал ?
Логика сходится - в оконный цикл всунуто ожидание, на него влияет калибровка таймера, так как шедулер вызывается более точно и соответственно есть видимый эффект, графика быстрее работает.

Вероятно такое же было и с ускорением при запуске иных апп. В очередь обработки гуя вставлено системное ожидание. Это может как тормозить всю оконную систему, так и разогнать её - есть глобальные сообщения и если их задержать, то встанет весь гуй. А как по вашему ?

-----
vx

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

difexacaw пишет:
А с чего ты всяз что нет ожидания в оконной процедуре, может он тебе свой код показал ?
Либо ты слепой, либо у тебя СДВ.

-----
2 оттенка серого

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

f13nd

Я не вижу от тебя ничего по теме вообще. Значит слепой.

-----
vx

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

diexaclaw, графика у меня рисуется в отдельном треде (даже нескольких), соответственно, все оконные сообщения обрабатываются вовремя, я не знаю, с чего ты взял, что я школьник и совсем не умею программировать? Я задавал вполне конкретный вопрос - с графическим движком всё ок, но почему-то подтормаживает отрисовка. Ты же начал втирать какую-то дичь про прерывания, синхронизацию в ядре, гуй-фильтры (кто-нибудь знает, что это вообще такое?). Реально помогли люди, рассказавшие мне про мультимедиа-таймеры, а твои сообщения, якобы написанные с дофигасмыслом, в итоге оказались лишь пердежом в лужу

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

difexacaw пишет:
А с чего ты взял что нет ожидания в оконной процедуре
Какой же ты мнительный

-----
IZ.RU

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

[X-Ray]

Если графика зависит от частоты прерываний, то этому есть одно только объяснение ^

> совсем не умею программировать?

Потому что ты не можешь профилировать свой же код.

> кто-нибудь знает, что это вообще такое?).

Все кроме тебя --> Link <--
Только школьники могут формы шлёпать не понимая основ гуя.

Добавлено спустя 16 минут
DenCoder

> Какой же ты мнительный

Не мнительный. Эта тема про гадание. ТС не провёл никакие замеры по таймингу, нет никакой инфы; где лог по сервисному профайлу?
Есть лишь несколько предложений не чётких, на которых можно строить предположения. Впрочем этого вполне достаточно что бы понять проблему.

-----
vx

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