UOpilot и windows10?, медленная работа функции color() Опции

[Mooncake]

Здравствуйте!

Запускаю следующий скрипт в uopilot, который измеряет время своего выполнения, без привязки к какому-либо окну

Код

--lua
local t = os.clock()
for i = 1, 100 do
    color(640,512)
end
log('---', os.clock()-t)

При запуске uopilot на win10 (с ПК) в режиме совместимости с win7 (без режима результат примерно тот же) вывод программы:
--- 1.968
--- 1.933
--- 1.928

При запуске uopilot на win7 (с ноута) вывод программы:
--- 0.062
--- 0.064
--- 0.059

UOpilot всегда запускается от Администратора при отключенном антивирусе. Производительность ПК с win10 намного выше, чем ноута с win7, т.е. с железом проблемы быть не может.

Подскажите, пожалуйста, что можно сделать!

[Mooncake]

Примечательно то, что, например, findcolor() работает на win10 и win7 примерно одинаково. Разница, конечно, есть (на win7 быстрее), но не на два порядка как в случае с color()!

[DarkMaster]

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

[Mooncake]

Спасибо!
Указание хэндла в функции color() действительно ускоряет работу ф-ции примерно в 6 раз!
Пилот везде последней версии 2.42 (15.05.2021).

Однако на win10 проблема удивительным образом сохраняется именно для игрового окна.
Я привязываюсь к разным окнам и измеряю время выполнения скрипта с color(). Для Telegram, Log Window пилота или Matlab это время 0,1-0,4 с. Но для игры Ragnarok Online время 1,7 с.
Т.е. для пилота это окно принципиально чем-то отличается от других, понять бы чем... помогите, если есть идеи

Код

--lua

local handle = findwindow('Ragnarok Online')
--local handle = findwindow('Telegram')
--local handle = findwindow('Log Window')
--local handle = findwindow('MATLAB R2023a')

if handle[1][1] then
    log('окно найдено')
    workwindow(handle[1][1])
else
    log('окна не найдено')
end

local t = os.clock()
for i = 1, 100 do
    color(50,50, handle[1][1])
end
log('---', os.clock()-t)

[cirus]

Чем больше фпс, тем быстрее получение цвета.

[Cockney]

Это эмпирические наблюдения или есть где почитать про это ? На моей памяти снятие скриншота/цвета быстрое возможно стабильно на вин7 (и скорее всего на висте, но не точно), ибо там отрисовка окон идет по хитрому, а в ХР, вин10 приходится лочить окно на момент снятия, что должно приводить к падению фпс. Не совсем понятно как высокий фпс собственно ускоряет, ибо оно должно только мешать.

[cirus]

Это эмпирические наблюдения или есть где почитать про это ?

Просто тестил в л2. В чём причина такого поведения не вникал.

[DarkMaster]

Это эмпирические наблюдения или есть где почитать про это ? На моей памяти снятие скриншота/цвета быстрое возможно стабильно на вин7 (и скорее всего на висте, но не точно), ибо там отрисовка окон идет по хитрому, а в ХР, вин10 приходится лочить окно на момент снятия, что должно приводить к падению фпс. Не совсем понятно как высокий фпс собственно ускоряет, ибо оно должно только мешать.

Старый метод снятия скринов - 30 фпс. Есть подозрение, что это как-то связано с вертиткальной синхронизацией на 60 фпс и делить на 2, но это чисто додумки. По л2 при захвате изображения по хендлу фактически скорость равняется фпсу (иногда могут прилетать малевичи, нужно фильтровать).

[Cockney]

Старый метод снятия скринов - 30 фпс. Есть подозрение, что это как-то связано с вертиткальной синхронизацией на 60 фпс и делить на 2, но это чисто додумки. По л2 при захвате изображения по хендлу фактически скорость равняется фпсу (иногда могут прилетать малевичи, нужно фильтровать).

Я не знаю что внутри старого метода. У меня он никогда не работал вообще. При снятии по хендлу скорость зависит от самой системы. Что значит скорость равна фпс ? Это получается, она стремится к нулю ? А если прилетают малевичи, то учитывая время на проверки, выходит не так и быстро (как и надежно, собственно)

[DarkMaster]

Тестил на л2. В л2 100 фпс - я получаю 100 финдов. в л2 300 фпс - я получаю 300 финдов. Погрешность около процента. Так что зависимость считаю явной. Малевичи 1 из 1000. Я уже очень давно не пишу надеясь на единичные сработки для мест, где это может привести к ошибкам либо негативным последствиям. Малевичи ловил только в л2. Возможно особенности приложения, либо просто не замечаю потому, что пишу через самописные функции ожидания изображений. У меня нет в коде конструкций типа:
if findimage()
там всегда будет что-то вроде:
if fi.image_name()
где image_name() будет некоторой функцией, которая будет вызывать мою базовую функцию поиска с ожиданием, таймаутами, проверками блинков и т.д. После перехода к данному стилю проблемы ушли почти все. Съехавшие координаты/изображения после патчей разве что остались, но это совсем другая история.

[yodich]

Тестил на л2. В л2 100 фпс - я получаю 100 финдов. в л2 300 фпс - я получаю 300 финдов. Погрешность около процента. Так что зависимость считаю явной. Малевичи 1 из 1000. Я уже очень давно не пишу надеясь на единичные сработки для мест, где это может привести к ошибкам либо негативным последствиям. Малевичи ловил только в л2. Возможно особенности приложения, либо просто не замечаю потому, что пишу через самописные функции ожидания изображений. У меня нет в коде конструкций типа:
if findimage()
там всегда будет что-то вроде:
if fi.image_name()
где image_name() будет некоторой функцией, которая будет вызывать мою базовую функцию поиска с ожиданием, таймаутами, проверками блинков и т.д. После перехода к данному стилю проблемы ушли почти все. Съехавшие координаты/изображения после патчей разве что остались, но это совсем другая история.

я все еще жду когда выложишь библу😎

[DarkMaster]

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

[yodich]

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

нормально все будет ) ждем)

[deNoor]

Чем больше фпс, тем быстрее получение цвета.

Я, конечно, не знаю, как делает пилот, но в сишарпике Graphics.CopyFromScreen(), который зовёт Gdi32.BitBlt(), который, судя по всему, терпеливо ждёт до ближайшего кадра. Получается, чем быстрее следующий кадр, тем быстрее вернётся, а само получение-отпускание девайс контекста (GetDC + ReleaseDC) и копирование очень быстрые. Ограничивается только ожиданием, чего бы тут покопировать. (IMG:style_emoticons/default/smile.gif)
Процессор не кушает, а именно что тихонько ждёт.

Замеры с высокоточным таймером (Stopwatch) для Graphics.CopyFromScreen + Bitmap.GetPixel:
— при копировании с 60 фпс (поставить в виндовс) десктопа без запущенных игр это как раз 1000/60 мс;
— для десктопа со 165фпс это 1000/165 мс;
— для игры с VSync ON + FPS Limit 158 (в драйвере нвидии aka Nvidia Control Panel), которая выдаёт эти 158 фпс, будет 1000/158 мс,
— для игры, которая крутит около 250 фпс с отключением вертикальной синхронизации и лимитера (в драйвере нвидии), аж через 1-2 мс возвращалась. Получается даже чаще каждого кадра, когда vsync не блочит. Пробы десктопа без запущенной игры так не могут. (IMG:style_emoticons/default/smile.gif)
Чёрных пикселей вместо реальных, на что иногда жалуются для пилота (малевичи), не было. Но игры диабло 3 и овервотч, которые новее линеаге.

Для копирования маленького куска пикселей вместо пробы одного: graphics.CopyFromScreen + bitmap.LockBits + Marshal.Copy(в свой управляемый массив) + bitmap.UnlockBits — замеры времени такие же.
Но для целого экрана 2560x1440 одно только копирование длится долго + ждать ближайший кадр — выходило около 18-24мс вместе (раз в 3-4 кадра для 165 фпс). Причём, отказ от Marshal.Copy в пользу щупания байтиков через указатель, выданный в LockBits(), ничего не изменил. Всё время съедает CopyFromScreen.

Такое вот для виндовс 11 22631.2861, Hardware-accelerated GPU scheduling - ON, Windowed Optimizations - ON.

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

[DarkMaster]

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