O navegador da web Chrome e também o Chromium agora habilitaram totalmente o suporte da plataforma Ozone X11 em canais beta e estáveis. Assim, além do código Ozone X11 do Chrome e Chromium agora totalmente ativado, o código X11 antigo legado está a ser removido.
Com o código de abstração da plataforma Ozone do Chrome, há um bom tempo os desenvolvedores têm trabalhado para fornecer um bom suporte para Wayland e X11 a partir da mesma construção . Usar o Ozone no X11 e X.Org era anteriormente uma opção experimental e agora passou com sucesso por um teste de origem neste verão.
O desenvolvedor da Igalia, Maksim Sisov, compartilhou neste fim de semana que o suporte da plataforma Ozone/X11 agora está “100% habilitado nos canais ESTÁVEL e BETA.” Com o ótimo estado agora desse suporte, eles estarão trabalhando para descontinuar caminhos não-Ozone/X11 e removendo esse caminho X11 legado em um futuro próximo.
Código Ozone X11 do Chrome e Chromium agora totalmente ativado
O Ozone é uma camada de abstração de plataforma abaixo do sistema de janelas Aura que é usado para entrada e gráficos de baixo nível. Depois de concluída, a abstração oferecerá suporte a sistemas subjacentes que variam de alvos SoC incorporados a novos sistemas de janela alternativos X11 no Linux, como Wayland ou Mir, para trazer o Aura Chromium ao fornecer uma implementação da interface da plataforma.
Mais detalhes sobre a camada da plataforma Ozone para os interessados em googlesource.com. Já faz muito tempo que se fala sobre o trabalho do Chrome Ozone, mais precisamente há quase uma década.
Algumas características
- Interfaces, não ifdefs. As diferenças entre as plataformas são tratadas chamando um objeto fornecido pela plataforma por meio de uma interface em vez de usar compilação condicional. As partes internas da plataforma permanecem encapsuladas e a interface pública atua como um firewall entre as camadas superiores neutras da plataforma (aura, blink, conteúdo etc.) e as camadas inferiores específicas da plataforma. A camada de plataforma é relativamente centralizada para minimizar o número de lugares que as portas precisam para adicionar código.
- Interfaces flexíveis. As interfaces da plataforma devem encapsular apenas o que o Chrome precisa da plataforma, com restrições mínimas na implementação da plataforma, bem como restrições mínimas no uso das camadas superiores. Uma interface excessivamente prescritiva é menos útil para portabilidade porque menos portas serão capazes de usá-la sem modificações. Outra forma de afirmar é que a camada da plataforma deve fornecer um mecanismo, não uma política.
- Vinculação de tempo de execução de plataformas. Evitar a compilação condicional nas camadas superiores nos permite construir várias plataformas em um binário e vinculá-las em tempo de execução. Permitimos isso e fornecemos um sinalizador de linha de comando para selecionar uma plataforma (
--ozone-platform) se vários estiverem habilitados. Cada plataforma tem uma definição de construção única (por exemploozone_platform_foo) que pode ser ligada ou desligada independentemente. - Plataformas fáceis fora da árvore. A maioria das portas começam como garfos. Alguns deles posteriormente mesclam seu código upstream, outros terão uma vida útil prolongada fora da árvore. Tudo bem, e devemos facilitar esse processo para estimular os portos e incentivar a jardinagem frequente de trocas de cromo no projeto posterior. Se jardinar uma porta fora da árvore for difícil, então esses projetos simplesmente enviarão código derivado de cromo desatualizado e potencialmente inseguro para os usuários. Uma maneira de dar suporte a esses projetos é fornecer uma maneira de injetar plataformas adicionais na construção, corrigindo apenas um arquivo
ozone_extra.gni.
Via Phoronix
