Программирование на Visual C++. Архив рассылки

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

В зависимости от ситуации потоки могут находиться в трех состояниях. Давайте посмотрим, что это за состояния. Во-первых, поток может выполняться, когда ему выделено процессорное время, т.е. он может находиться в состоянии активности. Во-вторых, он может быть неактивным и ожидать выделения процессора, т.е. быть в состоянии готовности. И есть еще третье, тоже очень важное состояние – состояние блокировки. Когда поток заблокирован, ему вообще не выделяется время. Обычно блокировка ставится на время ожидания какого-либо события. При возникновении этого события поток автоматически переводится из состояния блокировки в состояние готовности. Например, если один поток выполняет вычисления, а другой должен ждать результатов, чтобы сохранить их на диск. Второй мог бы использовать цикл типа "while (!isCalcFinished) continue;", но легко убедиться на практике, что во время выполнения этого цикла процессор занят на 100% (это называется активным ожиданием). Таких вот циклов следует по возможности избегать, в чем нам оказывает неоценимую помощь механизм блокировки. Второй поток может заблокировать себя до тех пор, пока первый не установит событие, сигнализирующее о том, что чтение окончено.

В системе выделяются два вида потоков – интерактивные, крутящие свой цикл обработки сообщений (такие, как главный поток приложения), и рабочие, представляющие собой простую функцию. Во втором случае поток завершается по мере завершения выполнения этой функции.

Заслуживающим внимания моментом является также способ организации очередности потоков. Можно было бы, конечно, обрабатывать все потоки по очереди, но такой способ далеко не самый эффективный. Гораздо разумнее оказалось ранжировать все потоки по приоритетам. Приоритет потока обозначается числом от 0 до 31, и определяется исходя из приоритета процесса, породившего поток, и относительного приоритета самого потока. Таким образом, достигается наибольшая гибкость, и каждый поток в идеале получает столько времени, сколько ему необходимо.

Иногда приоритет потока может изменяться динамически. Так интерактивные потоки, имеющие обычно класс приоритета Normal, система обрабатывает несколько иначе и несколько повышает фактический приоритет таких потоков, когда процесс, их породивший, находится на переднем плане (foreground). Это сделано для того, чтобы приложение, с которым в данный момент работает пользователь, быстрее реагировало на его действия.

Конечно, эта заметка не претендует на исчерпывающее описание использования многозадачности. Цель этой вводной статьи – заинтересовать темой. В дальнейшем мы с вами поговорим о таких вещах, как создание интерфейсных потоков и синхронизация между потоками. А если вы хотите посмотреть пример создания рабочего потока, то он рассматривался в рассылке №5 от 28 июня.

ВОПРОС-ОТВЕТ

Q. Все знают десктопные программы-ассистенты (screenmates/deskmates, MS Agent). Весь вопрос, что качественных, без артифактов, достаточно мало. Для реализации экранного помошника есть 2 различных подхода (если знаете еще, подскажите): – рисовать поверх десктопа, запоминать-востанавливать фон и т.д. Здесь сложно уследить за случаями, когда другие окна перекрывают место, где выводится текущий кадр персонажа, если на десктопе идет своя жизнь (меняются-появляются иконки, молчу про Drag'n'Drop) – использовать регионы, примеры есть на codeguru, но это достаточно трудоемкая штука – идея проста: создать полностью прозрачное окно и рисовать в нем просто текущий кадр с действием персонажа, не заботясь о том, на каком фоне его рисуешь, ведь окно прозрачное! Т.е. программа может просто рисовать постоянно меняющиеся картинки в таком прозрачном окне и это создаст эффект анимации персонажа, главное тут, чтобы любые изменения фона не влияли, т.е. просто добавление атрибута WS_EX_TRANSPARENT – это не то что нужно

Так вот, внимание, вопрос!

Знает ли кто, как можно создать такое полностью прозрачное-невидимое окно, которое при перемещении по экрану не тащит за собой кусок фона с предыдущего местоположения?

Кстати, на кодегуру прямого примера нет точно, а то что есть о том как рисовать прозрачные штучки — не то.

Valery Boronin

A₁ Нужно для каждой картинки, входящей в анимацию, делать для окна специальный регион, который включал бы в себя точки, принадлежащие изображению и не включал все остальные. Это можно сделать так (source ниже) : Создать пустой регион, выбрать картинку (bitmap), выбрать прозрачный цвет, проитись по bitmap и для каждого непрозрачного участка в каждой строке bitmap создать регион высотой 1 пиксел и прикомбинировать его к исходному региону. В конце операции установить получившийся регион окну.

void MakeBitmapRegion(HWND hwnd, int int bmp_id) {
 COLORREF back_color;
 CBitmap bmp;
 if (!bmp.LoadBitmap (bmp_id)) return;
 BITMAP bmp_o;
 bmp.GetObject(sizeof(BITMAP), (LPSTR)&bmp_o);
 int w = bmp_o.bmWidth;
 int h = bmp_o.bmHeight;
 HDC wnd_dc = GetDC(hwnd);
 if (hwnd == NULL) return;
 if (wnd_dc == NULL) return;
 HDC hdc_bmp = CreateCompatibleDC(wnd_dc);
 SelectObject(hdc_bmp, HBITMAP(bmp));
 back_color = GetPixel(hdc_bmp, 0, 0);
 int x, x0, y;
 HRGN tmp_rgn, wnd_rgn;
 wnd_rgn = CreateRectRgn(0,0,0,0);
 x = y = 0;
 for (y; y < h; y++) {
 while (x < w-1) {
 while(GetPixel(hdc_bmp, x, y) == back_color && x < w) x++;
 if (x != w) {
 x0 = x;
 while(GetPixel(hdc_bmp, x, y) != back_color && x < w) x++;
 tmp_rgn = CreateRectRgn(x0, y, x, y+1);
 CombineRgn(wnd_rgn, wnd_rgn, tmp_rgn, RGN_XOR);
 }
 }
 x = 0;
 }
 DeleteObject(tmp_rgn);
 DeleteDC(hdc_bmp);
 SetWindowRgn(hwnd, wnd_rgn, TRUE);
 DeleteObject(wnd_rgn);
}

Сергей Егоров

A₂ Как сделать полностью прозрачное окно, которое не тащит за собою кусок фона – понятно. Нужно просто перехватить сообщение WM_WINDOWPOSCHANGING и сказать системе, чтобы она не копировала содержимое окна. Для этого в структуре WINDOWPOS, указатель на которую передаётся в функцию окна, предусмотрен флаг SWP_NOCOPYBITS. В MFC обработчик может выглядеть примерно так:

void CMyWnd::OnWindowPosChanging(WINDOWPOS FAR* lpwndpos) {
 lpwndpos->flags |= SWP_NOCOPYBITS;
CWnd::OnWindowPosChanging(lpwndpos);
}

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

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

Alexander Shargin ([e-mail])

ОБРАТНАЯ СВЯЗЬ

К прошлому выпуску:

У меня есть два меленьких примечания к теме "Три способа подключения DLL":

1. При неявном подключении .lib файл можно добавить к проекту с помощью меню "Project\Add to project\Files", выбрав тип файлов *.lib. Об этом все, наверное, знают, но про это не было упоминания в статье.

2.По поводу отложенной загрузки. К сожалению, как сказано в MSDN, такое подключение не позволяет импортировать данные: "Imports of data cannot be supported. A workaround is to explicitly handle the data import yourself using LoadLibrary (or GetModuleHandle after you know the delay-load helper has loaded the DLL) and GetProcAddress.".

Sergey Kuryata

По поводу проблемы, описанной в конце статьи прошлого выпуска:

я не проделывал данных действий, но у меня всё слинковалось и заработало

обычная линковка

#pragma comment(lib, "Delayimp.lib")

проходит, может потому, что установлен SP для MSVC 6.0

Max Stepanov

В ПОИСКАХ ИСТИНЫ

Q. Возникла проблема… Существует sdi-приложение с CFormView-базированным видом. Существует несколько форм также основанных на CFormView. Необходимо динамически изменять основной вид на другие формы в процессе работы программы. Я так понимаю существует два пути. Первый – в OnCreate CMainFrame создавать все формы и потом сортировать их меняя z-порядок и второй – по мере необходимости создавать формы динамически.А вот с реализацией – :(. Или может я не прав? Заранее спасибо.

olegich

Это все на сегодня. Пока!

Алекс Jenter [e-mail] Красноярск, 2000.

Программирование на visual C++ Выпуск №24 от 19 ноября 2000 г.

Всем привет!

СТАТЬЯ

Как бороться с мерцанием

Вот наконец настал момент, когда работа над программой уже как бы закончена, все вылизано и подчищено, и шедевр вроде не глючит и даже заказчик кажется довольным. И все просто отлично… кроме одной мелочи – при изменении размеров окна элементы управления на форме сильно мерцают. Да, вроде бы мелочь. Да, многие коммерческие приложения тоже мерцают… даже ОЧЕНЬ многие.

Но все-таки от этого создается впечатление какой-то НЕИДЕАЛЬНОСТИ, недоделанности, что ли… И остается неприятный осадок в душе у вас (это еще полбеды!) – и у пользователей вашего приложения (а вот это намного серьезнее).

Windows в силу своего строения не позволит вам писать идеальные программы – даже если вы могли бы это делать – так как система сама далеко не идеальна. (Если кто знает идеальную – подскажите). В этой статье я хочу рассказать, как если уж не совсем убрать, то хотя бы значительно уменьшить такое мерцание, причем как это можно сделать буквально за несколько секунд (Правда звучит совсем как реклама? Мы уже столько ее наслушались, что иногда и мыслим ею ;-)

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

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

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