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

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

Более того, курсор может оказаться искаженным или вообще отсутствовать. Например, в видеорежимах Mode X используется нелинейная организация пикселей. Windows пытается вывести курсор мыши, но поскольку режимы Mode X не поддерживаются Windows GDI, изображение курсора портится. Кроме того, Windows не умеет выводить курсор мыши на вторичных видеоустройствах (например, на видеокартах с чипами 3Dfx). Вывод продолжает поступать на первичное видеоустройство независимо от того, какое устройство активно в данный момент, поэтому курсор мыши пропадает.

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

Раз курсор мыши отображается самим приложением, а не Windows, частота его прорисовки зависит от быстродействия приложения. Если приложение постоянно работает на 75 FPS, это будет приемлемо, но что если частота вывода кадров упадет до 30 FPS и ниже? С падением частоты курсор будет все медленнее реагировать на действия пользователя.

Существует множество причин, по которым приложение может иметь низкую частоту вывода кадров. Трехмерные приложения предъявляют особенно жесткие требования к системе и часто работают с частотой 30 FPS и менее. Но «тормозить» могут и обычные, не трехмерные приложения. Сложное приложение, выводящее сотни объектов, будет иметь низкий FPS (конечно, все зависит от компьютера и видеокарты). Кроме того, режимы High и True Color часто оказываются намного медленнее 8-битных режимов.

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

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

Эта глава посвящена решению, которое удовлетворяет всем перечисленным критериям. Сначала мы обсудим частичное обновление экрана (прямой блиттинг на первичную поверхность), а затем поговорим о том, как многопоточность обеспечивает обновление курсора, не зависящее от частоты вывода. Наконец, теория воплотится на практике в виде программы Cursor.

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

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

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

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

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

Итак, курсор мыши должен обновляться прямо на первичной поверхности. При очередном перемещении курсора необходимо выполнить два действия:

1. Стереть курсор в старом месте.

2. Нарисовать курсор в новом месте.

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

1. Восстановить фоновое изображение в старом месте.

2. Сохранить часть изображения в новом месте.

3. Нарисовать курсор в новом месте.

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

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

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

Чтобы справиться с мерцанием, можно обновлять изображение на внеэкранной поверхности. Мы копируем в нее обе области курсора (старую и новую), обновляем изображение, а затем копируем обе области обратно на первичную поверхность как единое целое. Алгоритм состоит из пяти этапов:

1. Скопировать объединение старой и новой областей курсора на вспомогательную поверхность.

2. Стереть старый курсор на вспомогательной поверхности.

3. Сохранить фоновое изображение, занятое новой областью курсора.

4. Нарисовать новый курсор на вспомогательной поверхности.

5. Скопировать содержимое вспомогательной поверхности на первичную поверхность.

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

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

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

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

1. Построить новый кадр во вторичном буфере.

2. Сохранить область вторичного буфера, где должен находиться курсор.

3. Нарисовать курсор на вторичном буфере.

4. Выполнить переключение страниц.

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

Когда все внимание сосредоточено на курсоре мыши, нетрудно забыть, что курсор — всего лишь часть нашего приложения. После появления курсора приложение не должно принципиально отличаться от рассмотренных выше, так что было бы нежелательно вставлять код ввода от мыши и обновления курсора в середину приложения. И даже если согласиться на это, как будет выглядеть этот код? Он должен постоянно проверять наличие новых данных от мыши. При обнаружении данных он обновляет курсор мыши; в противном случае продолжает свою нормальную работу. Постоянный опрос мыши замедлит приложение и усложнит его структуру. Более удачное решение — разделить приложение на две подзадачи, использовав многопоточность.

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

Сознаете вы это или нет, но вы уже знакомы с потоками и процессами. Каждый раз при запуске программы создается новый процесс. Процесс обеспечивает программу всем, что ей нужно для работы, включая один поток (thread). Этот стандартный поток (также называемый основным потоком — primary thread) используется для выполнения кода программы. Основной поток типичного процесса начинает работу с точки входа (для Windows-программ это функция WinMain()) и продолжает выполняться в соответствии со всеми циклами, условными операторами и вызовами функций. Основной поток завершается вместе с завершением процесса.

Однако ничто не ограничивает процесс одним потоком. Средства MFC или Win32 позволяют создавать дополнительные потоки, которые обычно используются для выполнения фоновых задач. Эти дополнительные потоки (иногда называемые рабочими потоками) работают независимо от основного потока (а также друг от друга). Каждый поток обладает собственным стеком, но системные ресурсы (такие, как файлы и динамическая память) используются потоками совместно.

Многопоточность приносит пользу при наличии нескольких задач, которые могут (хотя бы частично) работать одновременно. Код правильно написанного многопоточного приложения выглядит просто, потому что каждый поток выполняет свою конкретную задачу.

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

И последнее замечание: на однопроцессорном компьютере многопоточные приложения работают не быстрее однопоточных. Скорость возрастает лишь на многопроцессорном компьютере с многопроцессорной операционной системой (например, Windows NT).

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

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

Блокировку потока можно представить себе в виде цикла, непрерывно опрашивающего некоторую логическую переменную. Цикл продолжается до тех пор, пока переменная не примет значение TRUE. С технической точки зрения это не совсем точно, потому что заблокированный поток не производит активных опросов события. Вместо этого он приостанавливается, а система удаляет его из списка активных потоков. Лишь после того как блокирующее событие перейдет в установленное состояние, выполнение потока возобновляется. Соответственно заблокированный поток почти не расходует процессорного времени.

Блокировка потоков чаще всего используется для защиты совместных ресурсов от одновременного доступа со стороны нескольких потоков. Мутекс (mutex, сокращение от mutually exclusive, то есть «взаимоисключающий») представляет собой объект, который может в любой момент времени принадлежать лишь одному потоку, гарантируя безопасность доступа к связанному с ним ресурсу. Когда мутекс принадлежит некоторому потоку, все остальные потоки, пытающиеся получить его в свое распоряжение, блокируются до освобождения мутекса.

Критические секции (critical section), как и мутексы, используются для предотвращения одновременного доступа к ресурсу со стороны нескольких потоков. Однако если мутекс может синхронизировать межпроцессные потоки, критическая секция ограничивается потоками одного процесса. Ограничение компенсируется скоростью — критическая секция работает быстрее, чем мутекс.

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

Для многопоточного программирования Windows можно выбирать между классами MFC и потоковыми функциями Win32. Microsoft рекомендует использовать в MFC-приложениях классы потоков. Для работы с потоками в MFC предусмотрены следующие классы:

• CWinThread

• CSyncObject

• CEvent

• CCriticalSection

• CMutex

• CSemaphore

• CSingleLock

• CMultiLock

Класс CWinThread представляет отдельный поток. Он присутствует во всех приложениях, потому что класс CWinApp (базовый для класса DirectDrawApp) является производным от CWinThread. Этот экземпляр класса CWinThread представляет основной поток приложения; чтобы добавить новые рабочие потоки, следует создать объекты CWinThread.

Класс CSyncObject является виртуальным. Непосредственное создание экземпляров этого класса не разрешается; он существует лишь для того, чтобы обеспечивать функциональные возможности производных классов. Класс CSyncObject является базовым для классов CEvent, CCriticalSection, CMutex и CSemaphore. Объекты синхронизации, представленные этими классами, рассматривались в предыдущем разделе.

Классы CSingleLock и CMultiLock применяются для блокировки потоков по состоянию одного или нескольких событий. Класс CSingleLock блокирует поток до установки конкретного события, а CMultiLock — до установки одного или всех событий из заданного набора.

Позднее в этой главе мы воспользуемся классами CWinThread, CEvent, CCriticalSSection и CMultiLock.

Теперь мы знаем все необходимое и можем сосредоточиться на решении проблемы курсора. Чтобы курсор мыши обновлялся независимо от основного потока, мы воспользуемся отдельным рабочим потоком (я буду называть его потоком ввода). Прежде всего давайте поговорим о основном потоке.

Основной поток программы Cursor ведет себя почти так же, как и основные потоки всех остальных программ, рассмотренных нами. Он инициализирует DirectDraw, создает поверхности приложения, строит очередной кадр во вторичном буфере и переключает страницы для его отображения. Чтобы обеспечить работу потока ввода, нам придется возложить на основной поток следующие дополнительные задачи:

• создание и запуск потока ввода;

• обновление курсора перед каждым переключением страниц;

• синхронизацию с потоком ввода;

• завершение потока ввода.

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

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

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

Наконец, основной поток должен предупредить поток ввода о завершении приложения. Помните — поток ввода работает независимо от основного потока. Без извещения со стороны основного потока он не будет знать о том, что приложение собирается завершиться. Кроме того, основной поток не может просто остановить работу потока ввода; поток ввода должен завершиться сам при получении сигнала завершения от основного потока.

Поток ввода обладает более узкой специализацией по сравнению с основным потоком. Он должен делать следующее:

• обнаруживать ввод от мыши;

• обновлять курсор;

• синхронизироваться с основным потоком;

• обрабатывать сигнал завершения, полученный от основного потока.

Для получения ввода от мыши могут применяться две схемы: опрос и оповещение. Опрос плохо подходит для нашего случая, потому что поток ввода постоянно остается активным, даже если пользователь не работает с мышью. С другой стороны, если поток ввода блокируется до поступления новых данных от мыши, он почти не расходует лишнего процессорного времени. С помощью имеющегося в DirectInput механизма оповещения можно заблокировать поток ввода до тех пор, пока DirectInput не сообщит о поступлении новых данных.

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

Наконец, поток ввода отвечает за свое завершение. При получении сигнала от основного потока он должен прекратить работу.

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

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

Мы поступили правильно, удалив получение данных о перемещениях мыши из основного потока, но что делать с кнопками мыши? Необходимо придумать, как сообщать основному потоку об изменениях их состояния.

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

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

Программа Cursor использует описанную выше методику и выводит на экран изображение вращающейся спирали, меню задержки и курсор мыши. По умолчанию программа выводит кадры максимально часто, но меню задержки позволяет уменьшить частоту вывода за счет задержки в основном потоке (максимальная задержка равна 500 миллисекундам, при этом приложение замедляется до 2 FPS). Если бы курсор не управлялся отдельным потоком, его обновление происходило бы лишь с выводом очередного кадра. Но поскольку курсор мыши не зависит от основного потока, он нормально реагирует на действия пользователя при любой частоте вывода. Программа Cursor изображена на рис. 7.1.

Рис. 7.1. Программа Cursor

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

СОВЕТ

Как создать собственный курсор

Программа Cursor может работать с курсором любого размера. В версии программы на CD-ROM использован небольшой курсор (12×20 пикселей), но вы можете легко изменить этот стандартный размер. Для этого достаточно заменить cursor_08.bmp и/или cursor_24.bmp файлами с более крупными изображениями курсоров.

По умолчанию приложение работает в 8-битном видеорежиме и соответственно с 8-битным курсором. Многое зависит от вашего графического редактора, но, скорее всего, вы избавитесь от проблем с палитрой, если воспользуетесь файлом cursor_08.bmp с CD-ROM как шаблоном для создания нестандартного курсора. С курсором формата True Color дело обстоит проще, но, чтобы воспользоваться им, придется слегка подправить функцию SelectInitialDisplayMode(), чтобы активизировать беспалитровый видеорежим вместо палитрового.

Программа Cursor, как и все остальные программы этой книги, построена на базе структурных классов DirectDrawWin и DirectDrawApp. Эти классы остались неизменными, а вся специфика приложения реализуется классом CursorWin. На практике функциональность курсора мыши, вероятно, следовало бы встроить в структурный класс. И все же для наглядности я объединил код для работы с курсором со специфическим кодом приложения. Класс CursorWin приведен в листинге 7.1.

Листинг 7.1. Класс CursorWin

class CursorWin : public DirectDrawWin {

public:

 CursorWin();

protected:

 //{{AFX_MSG(CursorWin)

 afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);

 afx_msg void OnDestroy();

 afx_msg void OnActivate(UINT nState, CWnd* pWndOther,     BOOL bMinimized);

 //}}AFX_MSG

 DECLARE_MESSAGE_MAP()

private:

 int SelectDriver();

 int SelectInitialDisplayMode();

 BOOL CreateCustomSurfaces();

 void DrawScene();

 void RestoreSurfaces();

private:

 BOOL InitMouse();

 BOOL InitKeyboard();

 BOOL UpdateDelaySurface();

private:

 //------- Функции потока ввода ------

 static DWORD MouseThread(LPVOID);

 BOOL UpdateCursorSimpleCase(int curx, int cury, int oldcurx, int oldcury);

 BOOL UpdateCursorComplexCase(int curx, int cury, int oldcurx, int oldcury);

private:

 //------- Данные мыши -------

 static LPDIRECTINPUTDEVICE mouse;

 static CCriticalSection critsection;

 static CWinThread* mousethread;

 static CEvent* mouse_event[2];

 static int cursor_width;

 static int cursor_height;

 static LPDIRECTDRAWSURFACE cursor;

 static LPDIRECTDRAWSURFACE cursor_under;

 static LPDIRECTDRAWSURFACE cursor_union;

 static int curx, cury;

 static int oldcurx, oldcury;

 static CList<MouseClickData, MouseClickData> mouseclickqueue;

private:

 //------- Данные приложения -------

 LPDIRECTINPUT dinput;

 LPDIRECTINPUTDEVICE keyboard;

 LPDIRECTDRAWSURFACE coil[coil_frames];

 LPDIRECTDRAWSURFACE dm_surf;

 int dm_index;

 DWORD menubarfillcolor;

 HFONT largefont, smallfont;

};

Класс CursorWin объявляет три обработчика сообщений: OnCreate(), OnDestroy() и OnActivate(). Функция OnCreate() инициализирует DirectDraw, DirectInput и поток ввода. Функция OnDestroy() освобождает интерфейсы DirectX и завершает поток ввода. Функция OnActivate() обеспечивает захват мыши и клавиатуры на период активности приложения.

Следующие пять функций наследуются от класса DirectDrawWin:

• SelectDriver()

• SelectInitialDisplayMode()

• CreateCustomSurfaces()

• DrawScene()

• RestoreSurfaces()

Мы достаточно часто видели эти функции в других приложениях и знаем, что они делают, поэтому не будем рассматривать их. Исключением является функция DrawScene(), которая представляет некоторый интерес, потому что помимо создания нового кадра занимается синхронизацией основного потока с потоком ввода.

Затем объявляются функции InitMouse() и InitKeyboard(). Эти функции используются функцией OnCreate() и отвечают за инициализацию объектов DirectInput, предназначенных для работы с мышью и клавиатурой. Функция InitKeyboard() совпадает с одноименными функциями программ Qwerty и Smear из главы 6, поэтому она также не рассматривается. Однако функция InitMouse() помимо инициализации мыши запускает поток ввода. Вскоре мы рассмотрим эту функцию.

Функция UpdateDelaySurface() готовит к выводу поверхность меню задержки. Она выводит текст меню и выделяет текущую задержку.

Далее в классе CursorWin объявляются три функции потока мыши:

• MouseThread()

• UpdateCursorSimpleCase()

• UpdateCursorComplexCase()

Функция MouseThread() реализует поток ввода. Когда основной поток создает поток ввода, он передает указатель на статическую функцию MouseThread(). Созданный поток использует эту функцию в качестве точки входа и продолжает выполнять ее до возврата из функции или вызова функции AfxEndThread(). Функция MouseThread() обновляет изображение курсора с помощью функций UpdateCursorSimpleCase() и UpdateCursorComplexCase().

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

Обратите внимание: в число переменных мыши входят объекты классов CCriticalSection, CEvent и CWinThread, предназначенные для синхронизации двух потоков нашей программы.

Мы объявляем два указателя на объекты CEvent — один используется для оповещений DirectInput, а второй сигнализирует о завершении потока.

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

Наше знакомство с программой Cursor начинается с функции OnCreate(), которая отвечает за инициализацию DirectDraw, DirectInput и потока ввода. Функция OnCreate() приведена в листинге 7.2.

Листинг 7.2. Функция CursorWin::OnCreate()

int CursorWin::OnCreate(LPCREATESTRUCT lpCreateStruct) {

 HRESULT r=DirectInputCreate(AfxGetInstanceHandle(), DIRECTINPUT_VERSION, &dinput, 0);

 if (r!=DI_OK) {

  AfxMessageBox("DirectInputCreate() failed");

  return -1;

 }

 if (InitMouse()==FALSE)  return -1;

 if (InitKeyboard()==FALSE)  return -1;

 if (DirectDrawWin::OnCreate(lpCreateStruct) == -1) return -1;

 mousethread->ResumeThread();

 return 0;

}

Сначала OnCreate() инициализирует DirectInput функцией DirectInputCreate(). Затем мышь и клавиатура инициализируются функциями InitMouse() и InitKeyboard(), после чего вызывается функция DirectDrawWin::OnCreate(). Функция InitMouse(), которую мы рассмотрим чуть ниже, создает поток ввода, доступ к которому осуществляется через указатель mousepointer. Однако поток ввода создается в приостановленном состоянии, чтобы он не пытался преждевременно обращаться к первичной поверхности. Поток будет запущен лишь после инициализации DirectDraw. Приостановленный поток активизируется функцией CWinThread::ResumeThread().

Давайте рассмотрим функцию InitMouse(), чтобы получить общее представление об инициализации мыши и создании потока ввода. Функция InitMouse() приведена в листинге 7.3.

Листинг 7.3. Функция InitMouse()

BOOL CursorWin::InitMouse() {

 HRESULT r;

 r = dinput->CreateDevice(GUID_SysMouse, &mouse, 0);

 if (r!=DI_OK) {

  TRACE("CreateDevice(mouse) failed\n");

  return FALSE;

 }

 r = mouse->SetDataFormat(&c_dfDIMouse);

 if (r!=DI_OK) {

  TRACE("mouse->SetDataFormat() failed\n");

  return FALSE;

 }

 r = mouse->SetCooperativeLevel(GetSafeHwnd(),    DISCL_NONEXCLUSIVE | DISCL_FOREGROUND);

 if (r!=DI_OK) {

  TRACE("mouse->SetCooperativeLevel() failed\n");

  return FALSE;

 }

 DIPROPDWORD property;

 property.diph.dwSize=sizeof(DIPROPDWORD);

 property.diph.dwHeaderSize=sizeof(DIPROPHEADER); 

 property.diph.dwObj=0;

 property.diph.dwHow=DIPH_DEVICE;

 property.dwData=64;

 r = mouse->SetProperty(DIPROP_BUFFERSIZE, &property.diph);

 if (r!=DI_OK) {

  TRACE("mouse->SetProperty() failed (buffersize)\n");

  return FALSE;

 }

 mouse_event[mouse_event_index]=new CEvent;

 mouse_event[quit_event_index]=new CEvent;

 r = mouse->SetEventNotification(*mouse_event[mouse_event_index]);

 if (r!=DI_OK) {

  TRACE("mouse->SetEventNotification() failed\n");

  return FALSE;

 }

 mousethread=AfxBeginThread((AFX_THREADPROC)MouseThread, this, THREAD_PRIORITY_TIME_CRITICAL, 0, CREATE_SUSPENDED);

 return TRUE;

}

Функция InitMouse() состоит из семи этапов:

1. Инициализация устройства DirectInput, которое представляет мышь.

2. Выбор формата данных, получаемых от мыши.

3. Установка уровня кооперации для мыши.

4. Инициализация буфера данных мыши.

5. Создание двух объектов CEvent.

6. Инициализация механизма оповещений DirectInput.

7. Создание потока ввода.

На этапах 1-4 происходит нормальная инициализация DirectInput, подробно рассмотренная в главе 6, поэтому основное внимание будет уделено этапам 5, 6 и 7.

На этапе 5 создаются два динамических объекта CEvent, а полученные указатели сохраняются в маленьком массиве. Положение этих указателей в массиве определяется константами mouse_event_index и quit_event_index (которые равны 0 и 1 соответственно). Первое событие блокирует или активизирует поток ввода в зависимости от того, поступили ли от мыши новые данные. Второе событие сообщает потоку мыши о завершении приложения. Как мы вскоре увидим, указатели сохраняются в массиве для того, чтобы мы могли заблокировать поток мыши по двум событиям одновременно.

На этапе 6 функция SetEventNotification() интерфейса DirectInputDevice приказывает DirectInput устанавливать событие мыши при появлении новых данных. Функция SetEventNotification() получает один аргумент типа HANDLE, однако наш объект CEvent наследует оператор преобразования типа от класса CSyncObject, благодаря чему мы можем использовать объект CEvent так, словно он имеет тип HANDLE (тип HANDLE, в частности, используется потоковым API Win32 для представления событий).

На этапе 7 создается поток ввода от мыши. Я снова приведу соответствующий фрагмент листинга 7.2:

mousethread=AfxBeginThread((AFX_THREADPROC)MouseThread, this, THREAD_PRIORITY_TIME_CRITICAL, 0, CREATE_SUSPENDED);

Существуют и другие способы создания потоков, но функция AfxBeginThread() является самым простым вариантом. Она получает шесть аргументов, однако последние четыре имеют значения по умолчанию, так что обязательными являются лишь два аргумента. В нашем случае передается пять аргументов.

Первый аргумент AfxBeginThread — указатель на функцию, выполняемую новым потоком; в нашем случае используется функция MouseThread(). Второй аргумент — значение, которое передается функции потока при вызове. Мы передаем указатель this, чтобы функция MouseThread() могла обращаться к членам нашего класса.

Третий аргумент — приоритет потока. По умолчанию для потока устанавливается нормальный приоритет (флаг THREAD_PRIORITY_NORMAL), но мы переопределяем его и задаем флаг THREAD_PRIORITY_TIME_CRITICAL, чтобы добиться наискорейшего отклика курсора.

Четвертый аргумент — размер стека для нового потока. Ноль означает, что размер стека выбирается по умолчанию. Пятый и последний аргумент определяет исходное состояние потока. Если он равен нулю, создается активный поток; в нашем случае использован флаг CREATE_SUSPENDED, чтобы создавался приостановленный поток.

На создании потока ввода работа функции InitMouse() заканчивается. Благодаря флагу CREATE_SUSPENDED поток ввода приостанавливается до момента, когда основной поток завершит инициализацию DirectDraw. Затем, перед возвратом из функции OnCreate(), поток ввода активизируется функцией ResumeThread() (см. листинг 7.2).

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

Листинг 7.4. Функция DrawScene()

void CursorWin::DrawScene() {

 //------ Проверить клавишу ESCAPE -------

 static char key[256];

 keyboard->GetDeviceState(sizeof(key), &key);

 if (key[DIK_ESCAPE] & 0x80) PostMessage(WM_CLOSE);

 //------ Обычные задачи ------

 ClearSurface(backsurf, 0);

 BltSurface(backsurf, dm_surf, 539, 0);

 static coil_idx;

 BltSurface(backsurf, coil[coil_idx], coilx, coily);

 coil_idx=(coil_idx+1)%coil_frames;

 //------ Начало синхронизированной секции ------

 critsection.Lock();

 //------ Сохранить область вторичного буфера под курсором

 RECT src;

 src.left=curx;

 src.top=cury;

 src.right=curx+cursor_width;

 src.bottom=cury+cursor_height;

 cursor_under->BltFast(0, 0, backsurf, &src, DDBLTFAST_WAIT);

 //------ Нарисовать курсор во вторичном буфере

 backsurf->BltFast(curx, cury, cursor, 0, DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT);

 primsurf->Flip(0, DDFLIP_WAIT);

 while (primsurf->GetFlipStatus(DDGFS_ISFLIPDONE)!=DD_OK);

 // ничего не делать (ждать, пока закончится

 // переключение страниц)

 int x, y;

 BOOL newclick=FALSE;

 int count=mouseclickqueue.GetCount();

 while (count--) {

  MouseClickData mc=mouseclickqueue.RemoveTail();

  if (mc.button==0) {

   x=mc.x;

   y=mc.y;

   newclick=TRUE;

  }

 }

 critsection.Unlock();

 //------ Конец синхронизированной секции -------

 //------ Сделать паузу в соответствии с выбранной задержкой ----

 if (delay_value[dm_index]!=0) Sleep(delay_value[dm_index]);

 //------ Обновить меню задержки --------

 if (newclick) {

  int max_index=sizeof(delay_value)/sizeof(int)-1;

  int menux=screen_width-dm_width+dm_margin;

  int menuw=dm_width-dm_margin*2;

  if (x>=menux && x<=menux+menuw) {

   int index=(y-dm_header)/dm_entrysize;

   if (index>=0 && index<=max_index && index!=dm_index) {

    dm_index=index;

    UpdateDelaySurface();

   }

  }

 }

}

Функция DrawScene() состоит из семи этапов:

1. Проверка клавиши Escape.

2. Подготовка нового кадра во вторичном буфере.

3. Обновление курсора (также во вторичном буфере).

4. Переключение страниц.

5. Проверка очереди событий мыши.

6. Проверка очереди событий мыши.

7. Обновление поверхности меню задержки.

Первый этап выполняется функцией GetDeviceState() интерфейса DirectInputDevice. Если будет обнаружено нажатие клавиши Escape, функция посылает сообщение WM_CLOSE, сигнализируя о завершении приложения.

Подготовка вторичного буфера (этап 2) включает его стирание и последующее копирование в него внеэкранной поверхности. Для перебора поверхностей из массива coil используется статическая целая переменная (массив coil подготавливается функцией CustomSurfaces(), которую мы не рассматриваем).

На этапах 3, 4 и 5 программа обращается к ресурсам, используемым потоком ввода, поэтому необходимо воспользоваться критической секцией. Объект класса CCriticalSection (critsection), объявленный в классе CursorWin (см. листинг 7.1), блокируется функцией Lock(). Эта функция пытается получить доступ к критической секции. Если попытка оказывается удачной, функция захватывает критическую секцию и завершается. После этого можно смело работать с совместными ресурсами — поток заведомо обладает монопольным правом доступа к ним. Если функции Lock() будет отказано в доступе (из-за того что критическая секция в данный момент захвачена потоком ввода), функция Lock() блокирует основной поток до освобождения критической секции.

На этапе 3 мы сохраняем содержимое области вторичного буфера, занятой курсором, а затем рисуем курсор в буфере. Обе операции выполняются функцией BltFast() интерфейса DirectDrawSurface.

На этапе 4 выполняется переключение страниц, однако оно происходит сложнее, чем обычно. Это связано с тем, что функция Flip() интерфейса DirectDrawSurface на самом деле не выполняет переключения. Она лишь приказывает видеокарте переключить страницы и после этого завершается. Фактическое переключение страниц происходит после того, как будут закончены все ранее начатые операции блиттинга во вторичный буфер. Для наших целей этого недостаточно. Нам нужно, чтобы переключение страниц было закончено до кода критической секции, потому что в противном случае поток ввода сможет обновить первичную поверхность во время переключения страниц. С помощью цикла while и функции GetFlipStatus() интерфейса DirectDrawSurface мы опрашиваем DirectDraw до тех пор, пока переключение страниц не закончится (в DirectDraw не предусмотрена блокировка по этой операции, но даже если бы она и была, переключение страниц происходит слишком быстро и не оправдывает блокировки потока).

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

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

Этап 6 не требует синхронизации, поэтому мы вызываем функцию CCriticalSection::Unlock(). Если к этому моменту поток ввода был заблокирован и ожидал доступа к своей критической секции, вызов Unlock() позволит ему войти в нее.

На этапе 7 обновляется поверхность меню задержки — хороший пример кода, который следовало бы спрятать в отдельном классе управления меню. Но, как уже говорилось в этой главе, я решил сократить количество функций и классов в этой программе, поэтому большая часть кода осталась «сырой». Так или иначе, на этапе 7 мы проверяем координаты последнего нажатия левой кнопки мыши и в соответствии с ними обновляем меню.

Теперь мы знаем, как происходит обновление экрана в основном потоке. Давайте посмотрим, как работает поток ввода.

Если не считать двух вспомогательных функций, весь поток ввода реализован в виде одной функции. Функция MouseThread() приведена в листинге 7.5.

Листинг 7.5. Функция MouseThread()

DWORD CursorWin::MouseThread(LPVOID p) {

 TRACE("starting mouse thread\n");

 CursorWin* win=(CursorWin*)p;

 while(TRUE) {

  CMultiLock mlock((CSyncObject**)mouse_event, 2);

  DWORD event=mlock.Lock(INFINITE, FALSE);

  if (event-WAIT_OBJECT_0==quit_event_index)  {

   TRACE("got quit message: quitting mouse thread\n");

   return 0;

  }

  critsection.Lock();

  oldcurx=curx;

  oldcury=cury;

  BOOL buffer_empty=FALSE;

  while (!buffer_empty) {

   DIDEVICEOBJECTDATA data;

   DWORD elements=1;

   if (mouse==0) {

    TRACE("invalid pointer: quitting mouse thread\n");

    return 0;

   }

   HRESULT r=mouse->GetDeviceData(sizeof(data), &data, &elements, 0);

   if (r==DI_OK && elements==1)   {

    static MouseClickData mc;

    switch data.dwOfs) {

    case DIMOFS_X:

     curx+=data.dwData;

     break;

    case DIMOFS_Y:

     cury+=data.dwData;

     break;

    case DIMOFS_BUTTON0:

     if (data.dwData & 0x80) {

      mc.x=curx;

      mc.y=cury;

      mc.button=0;

      mouseclickqueue.AddHead(mc);

     }

     break;

    case DIMOFS_BUTTON1:

     if (data.dwData & 0x80) {

      mc.x=curx;

      mc.y=cury;

      mc.button=1;

      mouseclickqueue.AddHead(mc);

     }

     break;

    }

   } else buffer_empty=TRUE;

  }

  if (curx<0) curx=0;

  if (cury<0) cury=0;

  if (curx>=screen_width-cursor_width) curx=screen_width-cursor_width-1;

  if (cury>=screen_height-cursor_height) cury=screen_height-cursor_height-1;

  if (curx==oldcurx && cury==oldcury) {

   //----- обновление курсора не требуется ------

   goto nevermind;

  } else if (abs(curx-oldcurx) >= cursor_width || abs(cury-oldcury) >= cursor_height) {

   //----- простой случай: прямоугольники нового

   // и старого курсора не перекрываются -----

   win->UpdateCursorSimpleCase(curx, cury, oldcurx, oldcury);

  } else {

   //----- сложный случай: прямоугольники нового

   // и старого курсора перекрываются -----

   win->UpdateCursorComplexCase(curx, cury, oldcurx, oldcury);

  }

  nevermind:;

  critsection.Unlock();

 }

 TRACE("leaving mouse thread\n");

 return 0;

};

Функция MouseThread() имеет один параметр — значение, передаваемое функции AfxBeginThread() при создании потока (см. листинг 7.3). Мы передавали указатель this, поэтому сейчас сможем присвоить его значение указателю на класс CursorWin (переменная win). В функции MouseThread() указатель win будет использоваться для доступа к членам класса CursorWin.

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

Когда любое из двух событий переходит в установленное состояние, функция Lock() завершается, и мы проверяем код возврата. Если выясняется, что было установлено событие завершения потока (обозначенное константой quit_event_index), мы выходим из функции MouseThread(), тем самым завершая поток. В противном случае активизация потока вызвана событием мыши, поэтому мы переходим к обработке новых данных.

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

Мы в цикле получаем данные от объекта DirectInputDevice, представляющего мышь, с помощью функции GetDeviceData(). Если получены данные о перемещении мыши, происходит обновление переменных curx и cury. Если получены данные о нажатии кнопок, они заносятся в очередь событий.

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

Наконец, мы проверяем новое положение курсора. Если перемещение курсора не обнаружено, критическая секция освобождается, а объект CMultiLock снова используется для блокировки по обоим событиям. Если курсор переместился в другое положение, мы вызываем одну из двух функций обновления курсора в зависимости от того, перекрывается ли старая область курсора с новой. Если области перекрываются, вызывается функция UpdateCursorComplexCase(); в противном случае вызывается функция UpdateCursorSimpleCase().

Начнем с более простой функции UpdateCursorSimpleCase() (см. листинг 7.6).

Листинг 7.6. Функция UpdateCursorSimpleCase()

BOOL CursorWin::UpdateCursorSimpleCase(int curx, int cury, int oldcurx, int oldcury) {

 RECT src;

 HRESULT r;

 //------ Блиттинг 1: стирание старого курсора ----------

 r=primsurf->BltFast(oldcurx, oldcury, cursor_under, 0, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 1 failed\n");

  CheckResult(r);

 }

 //------ Блиттинг 2: сохранение области под новым курсором ------

 src.left=curx;

 src.top=cury;

 src.right=curx+cursor_width;

 src.bottom=cury+cursor_height;

 r=cursor_under->BltFast(0, 0, primsurf, &src, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 2 failed\n");

  CheckResult(r);

 }

 //------ Блиттинг 3: рисование нового курсора ----------

 r=primsurf->BltFast(curx, cury, cursor, 0, DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 3 failed\n");

  CheckResult(r);

 }

 return TRUE;

}

С помощью трех последовательных вызовов функции BltFast() интерфейса DirectDrawSurface, функция UpdateCursorSimpleCase() стирает существующий курсор, сохраняет область под новым курсором и рисует новый курсор.

В UpdateCursorComplexCase() функция BltFast() вызывается пять раз. Два дополнительных блиттинга предназначены для копирования обновляемой части первичной поверхности на вспомогательную поверхность (cursor_union) и обратно. Функция UpdateCursorComplexCase() приведена в листинге 7.7.

Листинг 7.7. Функция UpdateCursorComplexCase()

BOOL CursorWin::UpdateCursorComplexCase(int curx, int cury, int oldcurx, int oldcury) {

 RECT src;

 HRESULT r;

 int unionx=min(curx, oldcurx);

 int uniony=min(cury, oldcury);

 int unionw=max(curx, oldcurx)-unionx+cursor_width;

 int unionh=max(cury, oldcury)-uniony+cursor_height;

 //----- Блиттинг 1: копирование объединяющего прямоугольника

 // во вспомогательный буфер --------

 src.left=unionx;

 src.top=uniony;

 src.right=unionx+unionw;

 src.bottom=uniony+unionh;

 r=cursor_union->BltFast(0, 0, primsurf, &src, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 1 failed\n");

  CheckResult(r);

 }

 //------ Блиттинг 2: стирание старого курсора

 // во вспомогательном буфере ---------

 r=cursor_union->BltFast(oldcurx-unionx, oldcury-uniony, cursor_under, 0, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 2 failed\n");

  CheckResult(r);

 }

 //------ Блиттинг 3: сохранение области под новым курсором -----

 src.left=curx-unionx;

 src.top=cury-uniony;

 src.right=src.left+cursor_width;

 src.bottom=src.top+cursor_height;

 r=cursor_under->BltFast(0, 0, cursor_union, &src, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 3 failed\n");

  CheckResult(r);

 }

 //------ Блиттинг 4: рисование нового курсора

 // во вспомогательном буфере ---------

 r=cursor_union->BltFast(curx-unionx, cury-uniony, cursor, 0, DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 4 failed\n");

  CheckResult(r);

 }

 //------- Блиттинг 5: копирование вспомогательного буфера

 // на первичную поверхность --------

 src.left=0;

 src.top=0;

 src.right=unionw;

 src.bottom=unionh;

 r=primsurf->BltFast(unionx, uniony, cursor_union, &src, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 5 failed\n");

  CheckResult(r);

 }

 return TRUE;

}

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

Осталось лишь поговорить о том, как завершается работа приложения. Эта тема неоднократно рассматривалась, и ее можно было бы пропустить, но для программы Cursor она важна из-за наличия дополнительного потока. Мы должны не только послать потоку ввода сигнал о завершении, но и проследить за тем, чтобы поток завершился до уничтожения объекта устройства мыши и поверхностей DirectDraw. В противном случае он может попытаться обратиться к мыши или обновить первичную поверхность после того, как соответствующие объекты перестанут существовать. Функция OnDestroy() выглядит так:

void CursorWin::OnDestroy() {

 critsection.Lock();

 DirectDrawWin::OnDestroy();

 if (mouse) {

  TRACE("mouse->Unacquire()\n");

  mouse->Unacquire();

  TRACE("sending mouse quit message...\n");

  mouse_event[quit_event_index]->SetEvent();

  Sleep(100);

  // дать потоку мыши возможность ответить

  TRACE("Releasing mouse pointer...\n");

  mouse->Release(), mouse=0;

  delete mouse_event[mouse_event_index];

  delete mouse_event[quit_event_index];

 }

 if (keyboard) keyboard->Release(), keyboard=0;

 if (dinput) dinput->Release(), dinput=0;

 critsection.Unlock();

}

Когда MFC вызывает функцию OnDestroy(), основной поток заведомо не обновляет экран, потому что он занят выполнением этой функции. Тем не менее мы не знаем, не обновляется ли экран потоком ввода. Чтобы поток ввода закончил последнее обновление, мы блокируем критическую секцию.

Далее мы уступаем мышь. Устройство перестает генерировать новые события, которые заставили бы поток ввода попытаться снова обновить экран. Затем функция CEvent::SetEvent() посылает потоку ввода сигнал о завершении.

Нам осталось лишь освободить объекты DirectInput. Но перед тем, как это делать, мы вызываем функцию Sleep(), чтобы ненадолго приостановить основной поток. Поток ввода получает возможность обработать событие и завершиться. Наконец, мы освобождаем критическую секцию, и функция завершается — на этом работа приложения заканчивается.

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