Greenfield é resultado de um trabalho de quase dois anos que fornece um compositor HTML5 Wayland no navegador. Esse projeto de código aberto permitiu que aplicativos Wayland remotos fossem executados em navegadores durante a execução de hosts remotos. Agora, o Greenfield pode executar aplicativos diretamente dentro do navegador da Web de um usuário por meio de encadeamentos do Web Worker. No entanto, a principal novidade é o lançamento do novo Wayland 1.17. O Wayland 1.17 não é o lançamento mais empolgante para os usuários finais, porém tem algumas melhorias mais básicas.
Como isso se dá?
Erik De Rijcke, que idealizou a Greenfield, anunciou que os aplicativos agora podem ser executados diretamente em navegadores graças aos Web Workers. Porém, para fazer isso, o aplicativo deve estar usando JavaScript ou WebAssembly.
Entre outros impedimentos, isso também requer um protocolo personalizado do Wayland para ser suportado pelo aplicativo. No entanto, uma vez executado, todo o trabalho é feito no navegador da web do cliente, em vez de ser executado remotamente em um servidor da web.
Um Web Worker é essencialmente um thread/process independente em seu navegador, completamente separado do thread principal. Executar aplicativos em um trabalhador da Web isola o código do cliente sem afetar o desempenho do compositor e fornece isolamento de clientes mal-intencionados, diz o anúncio oficial.
Até agora, há dois aplicativos básicos como exemplo no site de demonstração em preview.greenfield.app. Pelo menos nos primeiros testes rápidos, a experiência é muito melhor no Chrome do que no Firefox.
O Greenfield suporta aplicativos da web. No entanto, existem alguns pré-requisitos, como citamos anteriormente. Vamos a eles:
- Os aplicativos da Web devem ser escritos em JavaScript (ou WebAssly) para que pode ser executado em um Web Worker.
- Um aplicativo da Web deve renderizar seu conteúdo para um ArrayBuffer como Web;
- Os workers não têm acesso ao DOM e, como tal, não podem usar HTML para
render seu conteúdo; - Como alternativa, os aplicativos da web podem renderizar um WebGL fora da tela
tela HTML5 acelerada. Infelizmente, este ainda é um HTML5 experimental spec; - Um aplicativo da Web deve se comunicar com o compositor usando um protocolo de buffer de Wayland;
- Um aplicativo Web Wayland pode ser executado diretamente dentro do navegador sem a
desvantagens da latência da rede ou da carga do servidor, enquanto ainda é capaz de
interoperar (copiar/colar e arrastar e soltar) com aplicativos nativos do lado do servidor
correndo diretamente ao lado dele.
Mais detalhes sobre este último trabalho do Greenfield através da lista de discussão Wayland.
Novo Wayland 1.17 lançado
O gerente de lançamento do Wayland, Derek Foreman, anunciou oficialmente o lançamento do Wayland 1.17, a primeira atualização oficial desde agosto do ano passado. Vamos conferir?
As novidades do Wayland 1.17
- O Wayland 1.17 tem alguns vazamentos de memória resolvidos e outras correções no código do scanner e testes;
- o protocolo wl_seat foi atualizado para exigir que os keymaps sejam privados;
- e talvez o mais importante ??com o Wayland 1.17 é o suporte para mensagens internas de erro do servidor. Essas mensagens de erro internas do servidor permitem notificar os clientes de bugs internos, pois até agora não havia como realizar esta tarefa. Esta é uma contribuição interessante para Wayland por Christopher James Halse Rogers da Canonical.
Existem também várias outras pequenas correções no Wayland 1.17. O breve anúncio de lançamento do Wayland 1.17 pode ser lido em wayland-devel.
Weston 6.0 como compositor de referência de Wayland também está chegando em breve, mas hoje Derek optou por lançar um RC2 ao invés de promovê-lo para o final em conjunto com o Wayland 1.17.
