O novo GNOME 42 trouxe uma mudança importante no compositor Mutter Wayland. Ele agora leva em consideração as sub-superfícies ao determinar as capacidades de varredura direta. Assim, dentro deste contexto, o GNOME On Wayland aprimora suporte de digitalização direta.
O Mutter do GNOME já suporta varredura direta para clientes de tela inteira. O objetivo é reduzir a latência e o uso de recursos para jogos e outros softwares de tela inteira. Isso evita qualquer cópia extra da tela do conteúdo da tela e, em vez disso, enviando o conteúdo do aplicativo ou jogo diretamente para a saída. No início desta semana, Mutter conseguiu suporte de feedback DMA-BUF para melhorar suas capacidades de varredura direta, particularmente para configurações multi-GPU/híbridas, enquanto na sexta-feira outra otimização foi incorporada.
GNOME On Wayland aprimora suporte de digitalização direta
Com esta fusão, o Mutter irá agora considerar as sub-superfícies de Wayland para varredura. Se um subsolo de Wayland for o ator principal, agora ele também será considerado para varredura direta.
Quem está se beneficiando diretamente com isso é o Mozilla Firefox no Wayland. Então, o navegador faz uso de sub-superfícies, caso você esteja executando-o em tela inteira, enquanto outros aplicativos também podem se beneficiar.
GNOME 42 vai permitir que Input Events aconteçam com capacidade máxima
Um novo desenvolvimento empolgante para o GNOME 42 é outro. Permitir que eventos de entrada aconteçam em sua taxa de dispositivo de entrada total. Isto é uma ótima notícia para jogadores de Linux com alta taxa de atualização, tablets de entrada e casos de uso semelhantes.
Notícias Relacionadas
Tecnologia móvel
Samsung destaca avanço nas mensagens RCS com suporte no iOS
O suporte a RCS chega ao iOS com o iOS 18.1, permitindo que usuários de Android e iPhone aproveitem uma experiência de mensagens aprimorada e sem necessidade de redes sociais.
Mercado elétrico
Xiaomi atinge R$ 7,14 bilhões em receita com veículos elétricos no 3º trimestre de 2024
Xiaomi fecha o 3º trimestre de 2024 com R$ 7,14 bilhões em receita com veículos elétricos, impulsionado pelo sucesso da série SU7, apesar do prejuízo operacional.
Até agora, o GNOME Shell tem compactado eventos de movimento do ponteiro para que sejam sincronizados com a taxa de atualização do monitor, que pode ser algo em torno de 30 a 144 eventos por segundo, dependendo da exibição. Para lidar com a renderização de jogos ou outro software com uma taxa de atualização superior à taxa de atualização e para aplicativos que utilizam velocidade, direção, aceleração para eventos de entrada, o GNOME 42 está mudando as coisas para melhor.
A taxa de dispositivo de entrada total varia de dispositivos diferentes. No entanto, geralmente desenhar tablets e mouses para jogos tendem a ser muito melhores do que o que é alcançado pelas taxas de atualização de tela de hoje, que é onde estará a diferença mais notável.
Veja a declaração
Tradicionalmente, o GNOME Shell tem compactado eventos de movimento do ponteiro para que seu manuseio seja sincronizado com a taxa de atualização do monitor, isso significa que os aplicativos normalmente veriam aproximadamente 60 eventos por segundo (ou 144 se você seguir as tendências).
Essa característica herdada dos primeiros dias da Clutter não era apenas um atalho, lidar com eventos de movimento implica procurar o ator que está sob o ponteiro (principalmente para sabermos para qual ator enviar o evento) e essa foi uma operação cara o suficiente para fazia sentido fazer com a frequência mais baixa possível. Se você é um leitor recorrente deste blog, deve se lembrar de como essa área obteve grandes melhorias no passado.
Mas isso por si só não é suficiente. Assim, os eventos de movimento também podem acabar sendo manipulados na área JS. É do interesse do GNOME Shell (e das pessoas reclamando da perda de frames) que não precisemos entrar no mecanismo JavaScript com muita frequência. Novamente, faz sentido manter o mínimo.
