GetPixel() работает нереально медленно на Windows 7

Написал программу (бот для онлайн игры), вся его работа заключается в получении цвета пикселя в нужных координатах и совершения тех или иных деййствий в зависимости от полученного цвета. Стояла ХР, все работало прекрасно, но вот решил попробовать семерку и столкнулся с необъяснимой вещью - бот нереально тупит. Например в самом начале он ищет окно игры в браузере (всмысле его координаты) а потом в этом окне находит нужную кнопку по ее цвету:
слегка быдлокод, т.к. писал "лишь бы работало" )) Но не об этом речь. В общем на ХР все эти действия происходят мнгновенно (для человеческого глаза), а на семерке на это уходит 5-6 секунд. По-моему нереальное время. Пробовал в диспетчере задач менять приоритет процесса - непомогло. Далее вся работа бота сводится к считываню цветов в определенных местах и реагированию на произошедшие события (цвет изменился - значит что-то случилось)), но естественно с такими темпами ни чего не работает. Вот сижу и думаю - почему на Win7 так медленно работают обычные API ?

Добавлено через 9 минут
поечему я решил что тормозит именно GetPixel()? - потому, что больше тут тормозить не чему)

1

попробуй CDC::GetPixel или CImage::GetPixel

0

Anton_Grey, на сколько я понял это MFC, я пишу пока без этого.

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

Добавлено через 8 часов 59 минут
Попробовал такой код:
перед этими двумя строчками и после них поставил breakpoint, чтоб посмотреть сколько этот код будет выполняться. На это ушло где-то около минуты. Это выходит за все допустимые рамки, в чем может быть дело?

0

Попробовал у себя, такая же проблема. Даже не знаю с чем связано.
Попробую на Wasm'e спросить.

0

Сообщение от Anton_Grey Попробую на Wasm'e спросить.

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

0

Я не специалист по графике. И практически не имею опыта работы под Windows. Но из общих соображений могу высказать причину тормозов. Тем более, что с похожей проблемой мы сталкивались с #pragma'ой, когда он использовал библиотеку SDL.

Любая работа с графикой - это работа с устройством (видеокартой) посредством драйвера. Видеокарта и драйвер как правило настроены таким образом, что самый эффективный способ обращения - страничный. Т.е. одним махом записывается целый кадр (экран) или одним махом считывается значение кадра. При таком раскладе чтобы отобразить точку делается чтение всего экрана, замена одной точки и потом запись всего экрана. Поэтому чтобы по точкам прорисовать экран при разрешении 640 на 480 требуется соответствующее количество последовательных чтений-записей всего экрана. Поэтому правильная работа заключается в том, что сначала в памяти формируется образ всей картинки, а потом оно одним махом отправляется на устройство.

Обратная работа (чтение точки с экрана), скорее всего, построена по тому же принципу. Читается весь экран, а потом выдаётся информация об одной точке. Тот факт, что на разных системах GetPixel работает с разной скоростью скорее всего говорит о следующем. При первом вызове GetPixel прочитается весь экран и выдастся значение конкретной точки. При последующем вызове делается проверка, изменилось ли состояние экрана с предыдущего вызова. Если не изменилось, то считываем значение точки в образе памяти, оставшемся от предыдущего вызова GetPixel (т.е. без обращения к устройству, которое очень медленное). Если изменилось, то ничего не остаётся делать, как заново прочитать весь экран. И в твоём случае проблема скорее всего растёт из того, что при последующем вызове считается, что состояние экрана изменилось. Это может зависет от конкретной реализации конкретного драйвера. В принципе, это может зависеть и от того, распахнуто окно программы во весь экран или нет, имеется ли какая-нибудь фигня в tray и прочей всякой лажи. Понятно, что в случае оконного приложения данные считываются не с экрана, а с виртуального устройства (оно Device Context или что-то в этом духе вроде бы называется), а потому возникает ещё куча программных прослоек, в которых могут возникать эти самые непонятки.

На мой взгляд проблему надо решать тем, что вместо кучи вызовов GetPixel нужно сделать один вызов, который читает весь образ экрана (а точнее, весь образ Device Context'а) в память, а дальше уже ковыряться в этой памяти. Независимо ни от чего такой вариант был бы куда более правильный, чем то, что у тебя написано, а потому даже если это не поможет, лучше работать именно так

Добавлено через 6 минут
Кстати, цикл в строках 14-20 - это какой-то мёртвый код, который 10 раз сравнивает две переменные, которые внутри цикла не меняются. По логике "clf=..." и "but.y++" должны находиться внутри цикла, а не снаружи. Ну вобщем ладно, это уже твоя кухня...

1

Сообщение от Evg Кстати, цикл в строках 14-20 - это какой-то мёртвый код, который 10 раз сравнивает две переменные, которые внутри цикла не меняются. По логике "clf=..." и "but.y++" должны находиться внутри цикла, а не снаружи. Ну вобщем ладно, это уже твоя кухня...

Точно, просто я 500 раз код переписывал, в процессе переписывания мог напортачить)

Добавлено через 4 минуты
Evg, скажи еще, разумно ли так делать:
где-то читал, что подобные циклы очень грузят ЦП.

0

Kastaneda, если не против могу ответить я)
Это действительно очень сильно загрузит ЦП. Обычно я поступаю так, если необходимо оперативно в реальном времени снимать какие то данне. создаю для этих нужд отдельный поток, в потоковой функции у меня следуйший код:
П.С. как пример, решения задачи.

Добавлено через 2 минуты
Так же можно приципить Event. То есть при необходимости дать знать потоку, что пора закончить работу.

1

Когда то делал GetPixel на vc++ на xp очень медленно пполучалось, перевел на делфи и скорость резко возраста. Это просто наблюдение мое частное.
На api не делал ни чего, но думаю можно создать свой dc CreateCompatibleDC и bitblt скопировать в него экран, а потом GetPixel.

0

Сообщение от bobrovskii если необходимо оперативно в реальном времени снимать какие то данне

Как раз есть такая необходимость, ну думаю если вставить Sleep(10); , то процессору это даст передышку (а для человеческого глаза будет незаметно). Еще пару вопросов:
По WInAPI ни чего не читал (вернее когда-то начинал читать книгу, потом забросил), осваиваю методом тыка, поэтому не понимаю, зачему нужно:
и еще

Так же можно приципить Event. То есть при необходимости дать знать потоку, что пора закончить работу.

Что такое Event ?

0

ReleaseDC если быть точным, то:

The ReleaseDC function releases a device context (DC), freeing it for use by other applications. The effect of the ReleaseDC function depends on the type of device context. It frees only common and window device contexts. It has no effect on class or private device contexts.

то есть освободить контекст, так то это обязательная процедура.
Event, CreateEvent сигналы.
Подробнее тоже можно узнать в MSDN, если есть время чуть поэже скину ЛС как пользоваться.

0

А чем чревато "забыть" включить в код ReleaseDC(). У меня в коде этого ни где не делается)
Вот твой код
Если ReleaseDC(hwnd, dc); вынести за цикл, чтоб каждый раз не получать HDC заново HDC dc = GetDC(hwnd);, чем это опасно?

0

Kastaneda, чем это черевато я точно тебе сказать не могу. вот что пишет тот же MSDN
в описании GetDC

After painting with a common device context, the ReleaseDC function must be called to release the device context. Class and private device contexts do not have to be released. The number of device contexts is limited only by available memory.

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

0

Да, но в пределах цикла HDC dc еще нужен. Думаю можно освободить его после цикла. Ладно, сейчас попробую сделать так, потом отпишусь)

0

Kastaneda, за приделами вызывай GetDC, думаю система не будет против)

0

Сообщение от Kastaneda Если ReleaseDC(hwnd, dc); вынести за цикл, чтоб каждый раз не получать HDC заново HDC dc = GetDC(hwnd);, чем это опасно?

Цикл while у тебя, грубо говоря, бесконечный. Чревато это тем, что ты никогда не освободишь. Пример из поста 12 как бы содержит 2 цикла: первый цикл while - он грузит процессор. Второй цикл - это sleep и он процессор не грузит. Так вот вся работа с контекстом у тебя находится вне второго цикла, но внутри первого. Рабочая часть кода (тело внутри первого цикла, кроме sleep'а) занимает гораздо меньшее время, чем второй цикл (sleep). Поэтому захват и освобождение контекста должны быть именно внутри этого короткого интервала времени, чтобы на период длительного второго цикла (а 500 миллисекунд с точки зрения процессора - это целая вечность) контекст находился в свободном состоянии

1

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

1

Сообщение от bobrovskii понимаю, хочется уменьшить код, но для коректной работы это не выход.

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

0

Evg, Respekt)

0

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

Уверен на 100% тормозит именно GetPixel(). Переписал код:
Быстрей не стало. На этот цикл потребовалось где 6-7 сек. (ну так, на глаз) При чем происходит где-то 150-200 итераций (это я тоже на глаз определил, исходя из моего разрешения экрана и местоположения окна игры). Ну не может быть такого , но факты говорят об обратном...

0