В прошлой статье я рассмотрел модель приложений Windows Runtime (WinRT) (msdn.microsoft.com/magazine/dn342867). Я показал, как написать приложение Windows Store или Windows Phone на стандартном C++ с применением классической COM, и На этот раз я покажу, как задействовать этот базовый скелет и добавить поддержку рендеринга. Модель приложений WinRT оптимизирована под рендеринг с помощью DirectX. Мы посмотрим, как использовать то, чему вы научились из моих предыдущих статей о рендеринге в Direct2D и Direct3D, и применим это к WinRT-приложению на основе CoreWindow, использующему Direct2Dспользуя только API-функции WinRT. При разработке таких приложений не предъявляется требование обязательно использовать какую-либо языковую проекцию вроде C++/CX или C#. Возможность обхода этих абстракций — важная особенность и отличный способ понять, как работает эта технология.
В статье из моей рубрики за май 2013 года я познакомил вас с Direct2D 1.1 и показал, как с его помощью осуществлять рендеринг в настольном приложении (msdn.microsoft.com/magazine/dn198239). А в следующей рубрике я описал библиотеку dx.h (доступна на dx.codeplex.com), которая радикально упрощает программирование DirectX на C++ (msdn.microsoft.com/magazine/dn201741).
Код, представленный в последней статье, был вполне достаточен, чтобы создать приложение на основе CoreWindow, но в нем не выполнялся никакой рендеринг.
На этот раз я покажу, как задействовать этот базовый скелет и добавить поддержку рендеринга. Модель приложений WinRT оптимизирована под рендеринг с помощью DirectX. Мы посмотрим, как использовать то, чему вы научились из моих предыдущих статей о рендеринге в Direct2D и Direct3D, и применим это к WinRT-приложению на основе CoreWindow, использующему Direct2D 1.1 через библиотеку dx.h. По большей части команды рисования Direct2D и Direct3D, которые вам понадобится писать, одинаковы независимо от того, ориентируетесь вы на настольную программу или на Windows Runtime. Однако есть некоторые небольшие различия, и уж, если на то пошло, все это по-разному соединяется друг с другом. Так что я начну с того места, на котором остановился в прошлый раз, и объясню, как отображать пиксели на экране.
Для корректной поддержки рендеринга окно должно распознавать определенные события — как минимум, изменения видимости и размера окна, а также изменения в логической конфигурации DPI экрана, выбранной пользователем. Как и в случае события Activated, о котором я рассказывал в прошлый раз, все эти новые события отправляются приложению через обратные вызовы COM-интерфейса. Интерфейс ICoreWindow предоставляет методы для регистрации на события VisibilityChanged и SizeChanged, но сначала нужно реализовать соответствующие обработчики. Эти два COM-интерфейса, которые я должен реализовать, во многом похожи на обработчик событий Activated с его шаблонами классов, генерируемых MIDL (Microsoft Interface Definition Language):
typedef ITypedEventHandler<CoreWindow *, VisibilityChangedEventArgs *> IVisibilityChangedEventHandler; typedef ITypedEventHandler<CoreWindow *, WindowSizeChangedEventArgs *> IWindowSizeChangedEventHandler;
Следующий COM-интерфейс, который нужно реализовать, — IDisplayPropertiesEventHandler, и, к счастью, он уже определен. Достаточно включить соответствующий заголовочный файл:
#include <Windows.Graphics.Display.h>
Кроме того, релевантные типы определены в следующем пространстве имен:
Кроме того, релевантные типы определены в следующем пространстве имен:
При наличии этих определений я могу обновить класс SampleWindow из своей прошлой статьи так, чтобы он наследовал и от этих трех интерфейсов:
struct SampleWindow : ... IVisibilityChangedEventHandler, IWindowSizeChangedEventHandler, IDisplayPropertiesEventHandler
Кроме того, я должен обновить свою реализацию QueryInterface, чтобы сообщать о поддержке этих интерфейсов. Это упражнение я оставлю вам. Конечно, как я говорил в прошлый раз, Windows Runtime безразлично, где именно реализованы эти обратные вызовы COM-интерфейса. Из этого следует, что Windows Runtime не предполагает, что IFrameworkView моего приложения (основной интерфейс, реализуемый классом SampleWindow) также реализует интерфейсы этих обратных вызовов. Поэтому, хотя QueryInterface должным образом обрабатывает запросы к этим интерфейсам, Windows Runtime не будет запрашивать их. Вместо этого нужно зарегистрироваться на получение соответствующих событий, и лучшее место для этого — в моей реализации метода Load интерфейса IFrameworkView. Напомню, что Load — это место, в которое вы должны помещать весь код для подготовки вашего приложения к начальному отображению на экране. Таким образом, я регистрируюсь на события VisibilityChanged и SizeChanged в методе Load:
EventRegistrationToken token; HR(m_window->add_VisibilityChanged(this, &token)); HR(m_window->add_SizeChanged(this, &token));
Это явным образом сообщает Windows Runtime, где найти реализации первых двух интерфейсов. Третий и последний интерфейс предназначен для события LogicalDpiChanged, но регистрация этого события обеспечивается интерфейсом IDisplayPropertiesStatics. Этот статический интерфейс реализуется WinRT-классом DisplayProperties. Чтобы получить его, я могу просто использовать шаблон функции GetActivationFactory (реализацию GetActivationFactory можно найти в моей прошлой статье):
ComPtr<IDisplayPropertiesStatics> m_displayProperties; m_displayProperties = GetActivationFactory<IDisplayPropertiesStatics>( RuntimeClass_Windows_Graphics_Display_DisplayProperties);
Данная переменная-член сохраняет указатель на этот интерфейс, поскольку мне понадобится вызывать его в различные моменты жизненного цикла окна. А пока можно просто зарегистрироваться на событие LogicalDpiChanged в методе Load:
HR(m_displayProperties->add_LogicalDpiChanged(this, &token));
Вскоре я вернусь к реализации этих трех интерфейсов. Теперь следует подготовить инфраструктуру DirectX. Мне потребуется стандартный набор обработчиков аппаратных ресурсов (device resource handlers), которые неоднократно обсуждались в моих предыдущих статьях:
void CreateDeviceIndependentResources() {}
void CreateDeviceSizeResources() {}
void CreateDeviceResources() {}
void ReleaseDeviceResources() {}В первом обработчике я могу создать или загрузить любые ресурсы, не специфичные для нижележащего Direct3D-устройства рендеринга. Следующие два предназначены для создания аппаратно-зависимых ресурсов. Лучше всего разделять ресурсы, специфичные и неспецифичные для размера окна. В конце все аппаратные ресурсы должны быть освобождены. Остальная инфраструктура DirectX полагается на то, что приложение корректно реализует эти четыре метода в соответствии со своими требованиями. Она предоставляет дискретные точки в приложении для управления ресурсами рендеринга, а также для эффективного создания и повторного использования этих ресурсов.
Теперь я могу включить файл dx.h, который берет на себя всю тяжелую работу, связанную с DirectX:
#include "dx.h"
И каждое Direct2D-приложение начинается с Direct2D-фабрики:
Factory1 m_factory;
Вы найдете ее в пространстве имен Direct2D, и обычно я включаю это пространство так:
using namespace KennyKerr; using namespace KennyKerr::Direct2D;
В библиотеке dx.h имеются дискретные пространства имен для Direct2D, DirectWrite, Direct3D, Microsoft DirectX Graphics Infrastructure (DXGI) и т. д. Большинство моих приложений интенсивно использует Direct2D, поэтому для меня это имеет смысл. А вы, разумеется, можете управлять пространствами имен так, как это нужно в вашем приложении.
Переменная-член m_factory представляет фабрику Direct2D 1.1. С ее помощью создается мишень рендеринга (render target), а также множество других аппаратно-независимых ресурсов (по мере необходимости). Я создам Direct2D-фабрику, а затем позабочусь, чтобы любые аппаратно-независимые ресурсы создавались на последнем этапе метода Load:
m_factory = CreateFactory(); CreateDeviceIndependentResources();
После того как метод Load возвращает управление, WinRT-класс CoreApplication немедленно вызывает метод Run интерфейса IFrameworkView.
Реализация метода Run в SampleWindow из моей прошлой статьи просто блокировалась, вызвав метод ProcessEvents диспетчера CoreWindow. Блокирование в таком стиле вполне адекватно, если ваше приложение будет выполнять рендеринг нечасто — лишь на основе каких-то событий. Но, возможно, вы реализуете игру или вам просто нужна какая-то анимация высокого разрешения. В этом случае бросаются в другую крайность — использование непрерывного цикла анимации, но скорее всего вы предпочтете нечто более разумное. Я реализую компромиссный вариант между этими крайностями. Сначала я добавлю переменную-член, которая будет отслеживать, видимо ли окно. Это позволит мне убавить интенсивность рендеринга, когда окно физически не видимо пользователю:
bool m_visible;
SampleWindow() : m_visible(true) {}После этого можно переписать метод Run, как показано на рис. 1.
Рис. 1. Цикл динамического рендеринга
auto __stdcall Run() -> HRESULT override
{
ComPtr<ICoreDispatcher> dispatcher;
HR(m_window->get_Dispatcher(dispatcher.GetAddressOf()));
while (true)
{
if (m_visible)
{
Render();
HR(dispatcher->
ProcessEvents(CoreProcessEventsOption_ProcessAllIfPresent));
}
else
{
HR(dispatcher->
ProcessEvents(CoreProcessEventsOption_ProcessOneAndAllPending));
}
}
return S_OK;
}Как и раньше, метод Run получает диспетчер CoreWindow. Затем входит в бесконечный цикл, постоянно выполняя рендеринг и обрабатывая любые оконные сообщения (в Windows Runtime их называют событиями), которые могут находиться в очереди. Однако, если окно невидимо, он блокируется до тех пор, пока не появится сообщение. Как приложение узнает об изменении видимости окна? Для этого предназначен интерфейс IVisibilityChangedEventHandler. Теперь я могу реализовать его метод Invoke для обновления переменной-члена m_visible:
auto __stdcall Invoke(ICoreWindow *,
IVisibilityChangedEventArgs * args) -> HRESULT override
{
unsigned char visible;
HR(args->get_Visible(&visible));
m_visible = 0 != visible;
return S_OK;
}Интерфейс, сгенерированный MIDL, использует unsigned char как портируемый булев тип данных. Я просто получаю текущее состояние видимости окна, используя предоставляемый указатель на интерфейс IVisibilityChangedEventArgs и соответственно обновляю переменную-член. Это событие генерируется всякий раз, когда окно скрывается или показывается, и такой вариант немного проще, чем в реализации для настольных приложений, поскольку он охватывает целый ряд сценариев, включая завершение приложения и управление электропитанием, не говоря уже о переключении между окнами.
Далее нужно реализовать метод Render, вызываемый методом Run на рис. 1. Именно здесь создается по запросу стек рендеринга (rendering stack) и формируются собственно команды рисования. Базовый скелет этого метода представлен на рис. 2.
Рис. 2. Скелет метода Render
void Render()
{
if (!m_target)
{
// Подготавливаем мишень рендеринга...
}
m_target.BeginDraw();
Draw();
m_target.EndDraw();
auto const hr = m_swapChain.Present();
if (S_OK != hr && DXGI_STATUS_OCCLUDED != hr)
{
ReleaseDevice();
}
}Метод Render должен выглядеть знакомым вам. У него та же базовая форма, которую я обрисовал ранее для Direct2D 1.1. Он начинает с создания мишени рендеринга. Сразу же за этим следуют команды рисования, отправляемые между вызовами BeginDraw и EndDraw. Поскольку мишенью рендеринга является контекст Direct2D-устройства, реальный вывод нарисованных пикселей на экран включает использование цепочки замен (swap chain). Попутно мне нужно добавить типы из dx.h, представляющие контекст устройства Direct2D 1.1, а также цепочку замен в DirectX версии 11.1. Последнюю можно найти в пространстве имен Dxgi:
DeviceContext m_target; Dxgi::SwapChain1 m_swapChain;
Завершается метод Render вызовом ReleaseDevice, если отображение терпит неудачу:
void ReleaseDevice()
{
m_target.Reset();
m_swapChain.Reset();
ReleaseDeviceResources();
}Этот код освобождает мишень рендеринга и цепочку замен. Он также вызывает ReleaseDeviceResources для освобождения любых аппаратно-зависимых ресурсов, таких как кисти, битовые карты или эффекты. Вызов метода ReleaseDevice в данном случае может показаться не существенным, но он крайне важен для надежной обработки потери устройства в DirectX-приложении. Без должного освобождения всех аппаратных ресурсов (любых ресурсов, так или иначе поддерживаемых графическим процессором) ваше приложение может не восстановиться после потери устройства и просто рухнет.
Затем я должен подготовить мишень рендера — эту часть я опустил в методе Render на рис. 2. Она начинается с создания Direct3D-устройства (библиотека dx.h по-настоящему упрощает и несколько последующих этапов):
auto device = Direct3D::CreateDevice();
Располагая Direct3D-устройством, я могу с помощью Direct2D-фабрики создать Direct2D-устройство и контекст этого устройства:
m_target = m_factory.CreateDevice(device).CreateDeviceContext();
Следующий шаг — создание цепочки замен окна. Сначала я получаю DXGI-фабрику от Direct3D-устройства:
auto dxgi = device.GetDxgiFactory();
Потом создаю цепочку замен для CoreWindow приложения:
m_swapChain = dxgi.CreateSwapChainForCoreWindow(device, m_window.Get());
Здесь библиотека dx.h снова намного облегчает мне жизнь, автоматически заполняя за меня структуру DXGI_SWAP_CHAIN_DESC1. После этого я вызываю метод CreateDeviceSwapChainBitmap, чтобы создать битовую карту Direct2D, которая будет представлять буфер невидимых поверхностей (back buffer) цепочки замен:
void CreateDeviceSwapChainBitmap()
{
BitmapProperties1 props(BitmapOptions::Target | BitmapOptions::CannotDraw,
PixelFormat(Dxgi::Format::B8G8R8A8_UNORM, AlphaMode::Ignore));
auto bitmap =
m_target.CreateBitmapFromDxgiSurface(m_swapChain, props);
m_target.SetTarget(bitmap);
}Этот метод должен сначала описать буфер невидимых поверхностей цепочки замен так, чтобы это было понятно Direct2D. BitmapProperties1 — версия Direct2D-структуры D2D1_BITMAP_PROPERTIES1 из dx.h. Константа BitmapOptions::Target указывает, что в качестве мишени контекста устройства будет использоваться битовая карта. Константа BitmapOptions::CannotDraw сообщает, что буфер невидимых поверхностей цепочки замен можно использовать только как вывод, но не ввод для других операций рисования. PixelFormat — это версия Direct2D-структуры D2D1_PIXEL_FORMAT из dx.h.
Определив свойства битовой карты, метод CreateBitmapFromDxgiSurface получает буфер невидимых поверхностей цепочки замен и создает для его представления битовую карту Direct2D. Тем самым контекст Direct2D-устройства может осуществлять рендеринг напрямую в цепочку замен, просто выбрав в качестве мишени битовую карту через метод SetTarget.
В методе Render мне нужно просто сообщить Direct2D, как масштабировать любые команды рисования согласно конфигурации DPI, установленной пользователем:
float dpi; HR(m_displayProperties->get_LogicalDpi(&dpi)); m_target.SetDpi(dpi);
Далее я вызываю обработчики аппаратных ресурсов в приложении для создания любых необходимых ресурсов. На рис. 3 показана полная последовательность инициализации устройства для метода Render.
Рис. 3. Подготовка мишени рендера
void Render()
{
if (!m_target)
{
auto device = Direct3D::CreateDevice();
m_target = m_factory.CreateDevice(device).CreateDeviceContext();
auto dxgi = device.GetDxgiFactory();
m_swapChain = dxgi.CreateSwapChainForCoreWindow(device, m_window.Get());
CreateDeviceSwapChainBitmap();
float dpi;
HR(m_displayProperties->get_LogicalDpi(&dpi));
m_target.SetDpi(dpi);
CreateDeviceResources();
CreateDeviceSizeResources();
}
// Рисование и представление... (см. рис. 2)Хотя изменение DPI корректно применяется сразу после создания контекста Direct2D-устройства, его конфигурацию нужно обновлять всякий раз, когда эта настройка меняется пользователем. Тот факт, что конфигурация DPI может измениться для выполняемого приложения, является новшеством Windows 8. И здесь на сцену выходит интерфейс IDisplayPropertiesEventHandler. Теперь можно просто реализовать его метод Invoke и соответственно обновлять устройство. Вот обработчик событий LogicalDpiChanged:
auto __stdcall Invoke(IInspectable *) -> HRESULT override
{
if (m_target)
{
float dpi;
HR(m_displayProperties->get_LogicalDpi(&dpi));
m_target.SetDpi(dpi);
CreateDeviceSizeResources();
Render();
}
return S_OK;
}Предполагая, что мишень (контекст устройства) уже создана, он получает текущее логическое значение DPI и просто пересылает его в Direct2D. Потом обращается к приложению для создания заново любых ресурсов, специфичных для размера устройства (device-size-specific resources), перед повторных рендерингом. Тем самым мое приложение может динамически реагировать на изменения в конфигурации DPI экрана. Наконец, окно должно динамически обрабатывать изменения в размере окна. Я уже подключил регистрацию события, поэтому просто добавляю реализацию метода Invoke в интерфейсе IWindowSizeChangedEventHandler, представляющем обработчик событий SizeChanged:
auto __stdcall Invoke(ICoreWindow *,
IWindowSizeChangedEventArgs *) -> HRESULT override
{
if (m_target)
{
ResizeSwapChainBitmap();
Render();
}
return S_OK;
}Осталось лишь изменить размер битовой карты цепочки замен вызовом метода ResizeSwapChainBitmap. И вновь это нужно делать осторожно. Такое изменение может и должно быть эффективной операцией, но только при условии ее корректности. Чтобы эта операция прошла успешно, сначала нужно гарантировать освобождение всех ссылок на эти буферы. Такие ссылки приложение может хранить как в явном, так и неявном виде. В данном случае ссылка хранится контекстом Direct2D-устройства. Целевое изображение — это битовая карта Direct2D, которую я создал для обертывания буфера невидимых поверхностей. Освободить ее достаточно легко:
m_target.SetTarget();
Затем можно вызвать метод ResizeBuffers цепочки замен для выполнения остальной работы, а потом вызвать необходимые обработчики аппаратных ресурсов приложения. На рис. 4 показано, как все это делается.
Рис. 4. Изменение размеров цепочки замен
void ResizeSwapChainBitmap()
{
m_target.SetTarget();
if (S_OK == m_swapChain.ResizeBuffers())
{
CreateDeviceSwapChainBitmap();
CreateDeviceSizeResources();
}
else
{
ReleaseDevice();
}
}Теперь можно добавить какие-либо команды рисования, и DirectX эффективно выполнит соответствующий рендеринг на мишени CoreWindow. В качестве простого примера вы могли бы создать кисть со сплошной закраской в обработчике CreateDeviceResources и присвоить ее какой-то переменной-члену:
SolidColorBrush m_brush; m_brush = m_target.CreateSolidColorBrush(Color(1.0f, 0.0f, 0.0f));
В методе Draw окна можно начать с очистки фона окна белым цветом:
m_target.Clear(Color(1.0f, 1.0f, 1.0f));
Затем использовать кисть и нарисовать простой красный прямоугольник:
RectF rect (100.0f, 100.0f, 200.0f, 200.0f); m_target.DrawRectangle(rect, m_brush);
Чтобы гарантировать корректное восстановление приложения после потери устройства, нужно обеспечить освобождение им кисти сразу после того, как необходимость в ней отпадает:
void ReleaseDeviceResources()
{
m_brush.Reset();
}И это все, что требуется для рендеринга приложения на основе CoreWindow с помощью DirectX. Конечно, если вы сравните это с моей статьей за май 2013 года, то наверняка приятно удивитесь тому, насколько проще работать с кодом, относящимся к DirectX, благодаря библиотеке dx.h. Но пока что в приложении еще очень много стереотипного кода, в основном связанного с реализацией COM-интерфейсов. И здесь очень пригодится C++/CX, который упрощает использование WinRT API в ваших приложениях.