Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Observação
Para aplicativos no Windows 10, recomendamos o uso de APIs Windows.UI.Composition em vez de DirectComposition. Para saber mais, veja Modernizar seu aplicativo da área de trabalho usando a camada Visual.
Este tópico descreve os componentes que compõem o Microsoft DirectComposition. Consiste nas seguintes secções.
Componentes de software
DirectComposition consiste nos seguintes componentes de software principais.
- Uma biblioteca de aplicativos de modo de usuário (dcomp.dll) que implementa a API pública baseada em COM (Component Object Model).
- Um mecanismo de composição de modo de usuário (dwmcore.dll) que está hospedado no processo DWM (Desktop Window Manager) (dwm.exe) e executa a composição real da área de trabalho.
- Um banco de dados de objetos de modo kernel (parte de win32k.sys) que comanda o aplicativo para o mecanismo de composição.
Uma única instância do mecanismo de composição manipula as árvores de composição DirectComposition para todos os aplicativos e a árvore de composição DWM, que representa toda a área de trabalho. Tanto o banco de dados de objetos do modo kernel quanto o mecanismo de composição do modo de usuário são instanciados uma vez por sessão, portanto, uma máquina do Terminal Server com vários usuários tem várias instâncias de ambos os componentes.
O diagrama a seguir mostra os principais componentes DirectComposition e como eles se relacionam entre si.
de arquitetura de nível superior DirectComposition
Biblioteca de aplicativos
A biblioteca de aplicativos DirectComposition é uma API pública baseada em COM com um único ponto de entrada simples que é exportado do dcomp.dll e retorna um ponteiro de interface para um objeto de dispositivo. O objeto device, por sua vez, tem métodos para criar todos os outros objetos, cada um dos quais é representado por um ponteiro de interface. Todas as interfaces DirectComposition herdam e implementam totalmente a interfaceIUnknown. Todos os métodos que aceitam interfaces DirectComposition verificam se a interface é implementada dentro do dcomp.dll ou se é implementada por outro componente. Como DirectComposition não é extensível, os métodos que usam interfaces como parâmetros retornam E_INVALIDARG se as interfaces não forem implementadas em dcomp.dll. A API não requer privilégios especiais; ele pode ser chamado por processos executados no nível mais baixo de acesso. No entanto, como a API não opera na sessão 0, ela não é adequada para serviços. Nesses aspetos, a API DirectComposition é semelhante a outras APIs do Microsoft DirectX, mais notavelmente Direct2D, Microsoft Direct3D e Microsoft DirectWrite.
Como o mecanismo de composição foi projetado exclusivamente para execução assíncrona, as propriedades do objeto na API DirectComposition são somente gravação. Todas as propriedades têm métodos setter, mas não métodos getter. As propriedades de leitura não são apenas intensivas em recursos, mas também podem ser imprecisas porque qualquer valor que o mecanismo de composição retorna pode se tornar imediatamente inválido. Isso pode acontecer se, por exemplo, uma animação independente estiver vinculada à propriedade que está sendo lida.
A API é thread-safe. Um aplicativo pode chamar qualquer método de qualquer thread a qualquer momento. No entanto, como muitos métodos de API devem ser chamados em uma sequência específica, sem qualquer sincronização, um aplicativo pode experimentar um comportamento imprevisível, dependendo de como os threads se intercalam. Por exemplo, se dois threads alterarem a mesma propriedade do mesmo objeto para valores diferentes ao mesmo tempo, o aplicativo não poderá prever qual dos dois valores será o valor final da propriedade. Da mesma forma, se dois threads chamarem Commit no mesmo dispositivo, nenhum thread terá um comportamento verdadeiramente transacional porque uma chamada para Commit em um thread enviará o lote de todos os comandos emitidos por ambos os threads, não apenas aquele que chamou Commit.
O sistema mantém todo o estado interno por objeto de dispositivo. Se um aplicativo cria dois ou mais objetos de dispositivo DirectComposition, o aplicativo pode manter lotes independentes e outro estado entre os dois.
Todos os objetos DirectComposition têm afinidade de objeto de dispositivo; Os objetos criados por um objeto de dispositivo específico podem ser usados somente com esse objeto de dispositivo e podem ser associados somente a outros objetos criados pelo mesmo objeto de dispositivo. Em outras palavras, cada objeto de dispositivo é uma ilha separada separada de funcionalidade. A única exceção é a classe visual, que permite a construção de árvores visuais onde um visual pode pertencer a um objeto de dispositivo diferente de seu pai. Isso permite cenários em que um aplicativo e um controle podem gerenciar uma única árvore de composição sem também precisar compartilhar um único objeto de dispositivo DirectComposition.
Motor de composição
O mecanismo de composição DirectComposition é executado em um processo dedicado, separado de qualquer processo de aplicativo. Um único processo de composição, dwm.exe, suporta cada aplicação numa sessão. Cada aplicativo pode criar duas árvores visuais para cada janela que possui. Todas as árvores são realmente implementadas como subárvores de uma árvore visual maior que também engloba as estruturas de composição do DWM. O DWM constrói uma grande árvore visual para cada área de trabalho em uma sessão. Aqui estão as principais vantagens desta arquitetura:
- O mecanismo de composição tem acesso a todos os bitmaps de aplicativos e árvores visuais, o que permite a interoperabilidade e a composição de janelas entre processos.
- O mecanismo de composição é executado em um processo de sistema confiável que é separado de qualquer processo de aplicativo, permitindo que aplicativos com baixos direitos de acesso componham conteúdo protegido com segurança.
- O mecanismo de composição pode detetar quando uma determinada janela está totalmente ocluída e evitar o desperdício de recursos da CPU e da unidade de processamento gráfico (GPU) compondo para a janela.
- O mecanismo de composição pode compor diretamente no buffer traseiro da tela, evitando a necessidade de uma cópia extra que é necessária para motores de composição por processo.
- Todas as aplicações partilham um único dispositivo Direct3D para composição, o que oferece poupanças de memória consideráveis
A árvore visual é uma estrutura retida. A API DirectComposition expõe métodos para editar a estrutura em lotes de alterações que são processadas atomicamente. O objeto raiz na API DirectComposition é o objeto device, que serve como fábrica para todos os outros objetos DirectComposition e contém um método chamado Commit. O mecanismo de composição não reflete as alterações que o aplicativo faz na árvore visual até que o aplicativo chame Commit, momento em que todas as alterações desde o último Commit são processadas como uma única transação.
O requisito para chamar Commit é semelhante ao conceito de "frame", exceto que, como o mecanismo de composição é executado de forma assíncrona, ele pode apresentar vários quadros diferentes entre chamadas para Commit. No DirectComposition, um de quadro é uma única iteração do mecanismo de composição, e o intervalo gasto por um aplicativo entre duas chamadas para Commit é chamado de lote.
O DirectComposition agrupa todas as chamadas de aplicativos para a API DirectComposition. O banco de dados de objetos do kernel, que é implementado no driver de sessão win32k.sys, armazena todas as informações de estado associadas às chamadas de API.
O motor de composição produz um quadro para cada branco vertical no visor. O quadro é iniciado em um espaço em branco vertical e tem como alvo o branco vertical subsequente. Quando o quadro é iniciado, o mecanismo de composição pega todos os lotes pendentes e inclui seus comandos nesse quadro. Os lotes são colocados em uma fila pendente quando o aplicativo chama Confirmare a fila pendente é liberada atomicamente no início do quadro. Portanto, há um único ponto no tempo que marca o início de um quadro. Todos os lotes enviados antes deste ponto são incluídos no quadro, enquanto todos os lotes enviados depois devem aguardar até que o próximo quadro seja processado. O ciclo completo de composição é o seguinte:
- Estime o tempo do próximo espaço em branco vertical.
- Recupere todos os lotes pendentes.
- Processe os lotes recuperados.
- Atualize todas as animações usando o tempo estimado na etapa 1.
- Determine as regiões da tela que precisam ser recompostas.
- Recomponha as regiões sujas.
- Apresente o quadro invertendo os buffers traseiro e frontal de cada tela.
- Se nada foi composto e apresentado nas etapas 6 e 7, aguarde até que um lote seja comprometido.
- Aguarde o próximo espaço em branco vertical.
Se houver vários monitores conectados a um único adaptador de vídeo, o mecanismo de composição usará o espaço em branco vertical do monitor primário para acionar o loop de composição e definir os tempos de amostragem da animação. Cada monitor é representado por uma cadeia de flip em tela cheia separada; o mecanismo de composição repete as etapas 6 e 7 para cada monitor, de forma round-robin, usando um único dispositivo Direct3D. Se também houver vários adaptadores de vídeo, o mecanismo de composição usa um dispositivo Direct3D separado para cada adaptador de vídeo nas etapas 6 e 7.
Os quadros de composição são programados para sempre começar em um espaço em branco vertical, como mostra a ilustração a seguir.
de agendamento de quadros de composição
Se o mecanismo de composição não tiver trabalho a fazer porque a árvore de composição não foi alterada, o thread de composição será suspenso enquanto aguarda um novo lote. Quando um novo lote é enviado, o fio de composição acorda, mas imediatamente volta ao modo de suspensão até o próximo vazio vertical. Esse comportamento garante tempos previsíveis de início e término do quadro para aplicativos e para o mecanismo de composição.
O mecanismo de composição publica os tempos de apresentação do quadro e a taxa de quadros atual. A publicação dessas informações permite que os aplicativos estimem o tempo de apresentação de seus próprios lotes, o que, por sua vez, permite que as animações sejam sincronizadas. Em particular, um aplicativo pode usar uma combinação de estatísticas de quadro do mecanismo de composição e um modelo histórico de quanto tempo seu thread de interface do usuário leva para produzir um lote, para determinar o tempo de amostragem para suas próprias animações.
Por exemplo, no início do lote de aplicativos mostrado na ilustração anterior, o aplicativo pode consultar o mecanismo de composição para determinar a hora exata de apresentação do próximo quadro. O aplicativo pode usar a hora atual, juntamente com informações sobre lotes anteriores que produziu, para determinar se o aplicativo pode concluir o lote atual antes do próximo vazio vertical. Portanto, o aplicativo usa o tempo de apresentação do quadro como o tempo de amostragem para suas próprias animações. Se o aplicativo determinar que é improvável concluir seu trabalho no branco vertical atual, o aplicativo pode usar o tempo de quadro subsequente como o tempo de amostragem, usando as informações de taxa de quadros retornadas pelo mecanismo de composição para calcular esse tempo.
Tópicos relacionados