Comparando a aceleração de hardware Direct2D e GDI
Direct2D e GDI são APIs de renderização 2D do modo imediato e oferecem algum grau de aceleração de hardware. Este tópico explora as diferenças entre Direct2D e GDI, incluindo diferenças passadas e presentes nos recursos de aceleração de hardware de ambas as APIs.
Este tópico tem as seguintes partes:
- Diferenças entre Direct2D e GDI
- Aceleração de hardware de Direct2D e GDI
- Renderização GDI no Windows 7
- Aceleração de Direct2D e GDI contrastante no Windows 7
- Conclusão
Diferenças entre Direct2D e GDI
O GDI renderiza geometrias opacas e com alias, como polígonos, reticências e linhas. Ele renderiza texto de alias e ClearType e pode dar suporte à combinação de transparência por meio da API AlphaBlend. No entanto, seu tratamento de transparência é inconsistente e a maioria das APIs de GDI simplesmente ignora o canal alfa. Poucas APIs GDI garantem o que o canal alfa conterá após uma operação. Mais importante, a renderização da GDI não é mapeada facilmente para operações 3D e uma GPU moderna é renderizada com mais eficiência na parte 3D de seu mecanismo de renderização. Por exemplo, as linhas com alias de Direct2D são projetadas para serem implementadas simplesmente como dois triângulos renderizados na GPU, enquanto a GDI usa o algoritmo de desenho de linha de Bresenham.
Direct2D renderiza primitivas opacas, transparentes, com alias e anti-alias. As interfaces do usuário modernas geralmente usam transparência e animação. Direct2D facilita a criação de uma interface do usuário moderna porque ela tem garantias estritas sobre como aceita e renderiza conteúdo transparente, e todos os seus primitivos são renderizados usando aceleração de hardware. Direct2D não é um superconjunto puro de GDI: primitivos que teriam sido injustificadamente lentos quando implementados em uma GPU não estão presentes em Direct2D. Como Direct2D é criado com essa ênfase na aceleração 3D, também é fácil de usar com Direct3D.
Desde Windows NT 4, a GDI foi executada no modo kernel. O aplicativo chama a GDI, que chama sua contraparte de modo kernel, que passa os primitivos para seu próprio modelo de driver. Esse driver envia os resultados para o driver de exibição do modo kernel global.
A partir do Windows 2000, a GDI e os drivers GDI foram executados em um espaço independente no kernel chamado "espaço de sessão". Um espaço de endereço de sessão é criado para cada sessão de logon e cada instância da GDI é executada independentemente nesse espaço de endereço no modo kernel distinto. Direct2D, no entanto, é executado no modo de usuário e passa comandos de desenho por meio do driver Direct3D do modo usuário para o driver do modo kernel.
Aceleração de hardware de Direct2D e GDI
A diferença mais importante entre Direct2D e aceleração de hardware GDI é a tecnologia subjacente que os impulsiona. Direct2D está em camadas no Direct3D e a GDI tem seu próprio modelo de driver, a DDI (Interface de Driver de Dispositivo) GDI, que corresponde aos primitivos GDI. O modelo de driver Direct3D corresponde ao que o hardware de renderização 3D em uma GPU renderiza. Quando a DDI GDI foi definida pela primeira vez, a maioria dos hardwares de aceleração de exibição tinha como alvo os primitivos GDI. Ao longo do tempo, mais e mais ênfase foi colocada na aceleração de jogos 3D e menos na aceleração do aplicativo. Como consequência, a API bitblt foi acelerada por hardware e a maioria das outras operações de GDI não foram.
Isso define o estágio para uma sequência de alterações na forma como a GDI é renderizada para a exibição. A ilustração a seguir mostra como a renderização de exibição GDI mudou do Windows XP para o Windows 7.
Também houve vários fatores adicionais que causaram alterações no modelo de driver GDI , conforme explicado abaixo.
Aumentar a complexidade e o tamanho dos drivers de exibição
Os drivers 3D tornaram-se mais complexos ao longo do tempo. O código mais complexo tende a ter mais defeitos, tornando benéfico para o driver existir no modo de usuário, em que um bug de driver não pode causar uma reinicialização do sistema. Como pode ser visto na figura acima, o driver de exibição é dividido em um componente complexo do modo de usuário e em um componente de modo kernel mais simples.
Dificuldade na sincronização de espaços de endereço de sessão e kernel global
No Windows XP, um driver de exibição existe em dois espaços de endereço diferentes: espaço de sessão e espaço de kernel. Partes do driver precisam responder a eventos como eventos de gerenciamento de energia. Isso precisa ser sincronizado com o estado do driver no espaço de endereço da sessão. Essa é uma tarefa difícil e pode levar a defeitos quando os drivers de exibição tentam lidar com esses espaços de endereço distintos.
Gerenciamento de janela composta
O DWM (Gerenciador de Janelas da Área de Trabalho), o gerenciador de janelas de composição introduzido no Windows 7, renderiza todas as janelas em superfícies fora da tela e, em seguida, as compõe para serem exibidas na tela. Isso requer que a GDI seja capaz de renderizar em uma superfície que será renderizada pelo Direct3D para exibição. Isso representava um problema no modelo de driver XP, já que GDI e Direct3D eram pilhas de driver paralelas.
Como resultado, no Windows Vista, o driver de exibição GDI DDI foi implementado como o CDD (Driver de Vídeo Canônico) fornecido pela Microsoft que renderizava o conteúdo GDI para um bitmap de memória do sistema a ser composto na tela.
Renderização GDI no Windows 7
O modelo de driver usado no Windows Vista exigia que cada janela GDI fosse apoiada por uma superfície de memória de vídeo e uma superfície de memória do sistema. Isso resultou no uso da memória do sistema para cada janela GDI.
Por esse motivo, a GDI foi alterada novamente no Windows 7. Em vez de renderizar para uma superfície de memória do sistema, a GDI foi modificada para renderizar para um segmento de memória de abertura. A memória de abertura pode ser atualizada da superfície de memória de vídeo que contém o conteúdo da janela. A GDI pode renderizar de volta para a memória de abertura e o resultado pode ser enviado de volta para a superfície da janela. Como o segmento de memória de abertura é endereçável pela GPU, a GPU pode acelerar essas atualizações para a superfície de memória de vídeo. Por exemplo, a renderização de texto, BitBlts, AlphaBlend, TransparentBlt e StretchBlt são aceleradas nesses casos.
Aceleração de Direct2D e GDI contrastante no Windows 7
Direct2D e GDI são APIs de renderização de modo imediato 2D e são aceleradas por hardware. No entanto, há várias diferenças que permanecem em ambas as APIs.
Local dos recursos
A GDI mantém seus recursos, em particular bitmaps, na memória do sistema por padrão. Direct2D mantém seus recursos na memória de vídeo no adaptador de vídeo. Quando a GDI precisa atualizar a memória de vídeo, isso deve ser feito no barramento, a menos que o recurso já esteja no segmento de memória de abertura ou se a operação puder ser expressa diretamente. Por outro lado, Direct2D pode simplesmente traduzir seus primitivos para primitivos Direct3D porque os recursos já estão na memória de vídeo.
Método de renderização
Para manter a compatibilidade, a GDI executa uma grande parte de sua renderização para a memória de abertura usando a CPU. Por outro lado, Direct2D converte suas chamadas de APIs em primitivas direct3D e operações de desenho. Em seguida, o resultado é renderizado na GPU. Algumas renderizações de GDI são executadas na GPU quando a memória de abertura é copiada para a superfície de memória de vídeo que representa a janela GDI.
Escalabilidade
Direct2D chamadas de renderização são todos fluxos de comando independentes para a GPU. Cada fábrica Direct2D representa um dispositivo Direct3D diferente. A GDI usa um fluxo de comando para todos os aplicativos no sistema. O método da GDI pode resultar em um acúmulo de sobrecarga de contexto de renderização de GPU e CPU.
Localização
Direct2D opera inteiramente no modo de usuário, incluindo o tempo de execução do Direct3D e o driver Direct3D do modo de usuário. Isso ajuda a evitar falhas do sistema causadas por defeitos de código no kernel. A GDI, no entanto, tem a maior parte de sua funcionalidade no espaço de sessão no modo kernel, com sua superfície de API no modo de usuário.
Disponibilidade de aceleração de hardware
A GDI é acelerada por hardware no Windows XP e acelerada no Windows 7 quando o Gerenciador de Janelas da Área de Trabalho está em execução e um driver WDDM 1.1 está em uso. Direct2D é acelerada por hardware em quase qualquer driver WDDM e se o DWM está ou não em uso. No Vista, a GDI sempre será renderizada na CPU.
Modelo de Apresentação
Quando o Windows foi projetado pela primeira vez, não havia memória suficiente para permitir que cada janela fosse armazenada em seu próprio bitmap. Como resultado, a GDI sempre é renderizada logicamente diretamente na tela, com várias regiões de recorte aplicadas para garantir que um aplicativo não seja renderizado fora de sua janela. No modelo de Direct2D, um aplicativo é renderizado em um buffer de fundo e o resultado é exibido quando o aplicativo termina de desenhar. Isso permite que Direct2D manipule cenários de animação muito mais fluidamente do que a GDI pode.
Conclusão
O código GDI existente continuará funcionando bem no Windows 7. No entanto, ao escrever um novo código de renderização de gráficos, Direct2D deve ser considerado, pois ele aproveita melhor as GPUs modernas.