Como um computador desenha uma janela?
Construindo uma pequena GUI do zero em Rust

Quando escrevemos println!, o terminal já sabe exibir caracteres. Uma interface gráfica começa um nível antes: precisamos pedir ao sistema operacional uma área na tela, manter um buffer de pixels, interpretar entradas, organizar componentes e redesenhar quando alguma coisa muda.

Nossa pergunta central será concreta: quem cria a janela, quem decide onde ela fica e como um retângulo colorido termina como luz no monitor? A resposta não cabe numa única peça. A CPU é o processador geral que executa as instruções do programa; a GPU é um processador especializado em operações gráficas paralelas. Elas cooperam com o sistema operacional, o compositor e o monitor, cada qual com um contrato diferente.

Uma CLI recebe uma linha, executa e produz texto. Uma TUI continua dentro do terminal, mas posiciona caracteres numa grade. Uma GUI mantém uma cena visual: janelas, painéis, textos e botões continuam existindo entre uma entrada e outra.

Quando a aplicação é iniciada, o sistema cria um processo. A thread principal abre a janela e entra num ciclo que permanece vivo enquanto ela existir. Se processo, thread, biblioteca e memória ainda parecem abstratos, vale retomar Como um computador executa um programa por dentro.

Se qualquer processo pudesse escrever livremente em qualquer ponto do monitor, uma aplicação apagaria a outra. No Ubuntu que usaremos neste artigo, o Wayland organiza essa convivência. Wayland é um protocolo — um conjunto de mensagens e regras — entre a aplicação cliente e o compositor. Cada aplicação entrega sua própria superfície, e o compositor decide como reuni-la com as demais na tela. A especificação oficial do protocolo Wayland descreve exatamente esses objetos.

O window manager decide posicionamento, tamanho, foco e decoração. O compositor recebe superfícies das aplicações, aplica posição, sombras, transparência e sobreposição e produz a cena final. Dependendo da plataforma, essas peças podem estar mais separadas ou integradas.

Para acompanhar esse caminho sem esconder etapas atrás de uma biblioteca gráfica, usaremos o Ubuntu 26.04 LTS com Wayland como ambiente de referência. Nosso código criará a superfície da janela, reservará uma área de memória compartilhada para os pixels, receberá mouse e teclado e entregará cada imagem pronta ao compositor.

Usaremos wayland-client e wayland-protocols para representar e transportar as mensagens oficiais do protocolo. Uma crate é um pacote de código Rust. Essas crates não fornecem janela pronta, botão, texto, layout ou desenho. A criação dos objetos Wayland, o buffer de pixels e toda a GUI continuam no nosso código.

[dependencies]
wayland-client = "0.31"
wayland-protocols = { version = "0.32", features = ["client"] }
tempfile = "3" # arquivo temporário usado pela memória compartilhada

Um monitor possui uma matriz física de pontos luminosos. Uma resolução de 1920 × 1080 descreve quantos pixels físicos existem na imagem exibida. A interface, porém, pode trabalhar com pixels lógicos. Em escala de 200%, uma caixa de 100 unidades lógicas ocupa aproximadamente 200 pixels físicos.

Essa separação existe porque a mesma quantidade física de pixels pode ocupar tamanhos muito diferentes. Sem escala, texto confortável num monitor antigo ficaria minúsculo numa tela moderna de alta densidade.

Uma tela não guarda “laranja” como palavra. Para cada pontinho da imagem, ela guarda uma pequena receita numérica. R é a quantidade de vermelho (red), G de verde (green) e B de azul (blue). Misturando essas três luzes obtemos a cor visível.

A quarta letra, A, vem de alpha e funciona como um controle de presença. Ela responde: “quanto desta cor deve aparecer sobre o que já estava atrás?”. Cada valor vai de 0 a 255 porque cabe em um byte: 0 significa nada; 255 significa o máximo.

#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub struct Color {
    pub r: u8,
    pub g: u8,
    pub b: u8,
    pub a: u8,
}

impl Color {
    pub const ORANGE: Self = Self {
        r: 237, g: 107, b: 50, a: 255
    };
}

Por que escrever as letras nessa ordem? Porque nosso programa precisa combinar onde cada número ficará na memória. Escolhemos vermelho, verde, azul e transparência: RGBA. Outros sistemas podem escolher outra ordem, mas isso não muda a ideia. Manter cada canal com um nome evita trocas acidentais. Para aprofundar cor, transparência e pixels, consulte Como um PNG funciona por dentro.

Imagine uma folha quadriculada. Cada quadradinho é um pixel e contém os quatro números RGBA que acabamos de conhecer. Nossa “folha” não é papel: é um espaço reservado na memória. Na computação gráfica, é comum chamar essa área de surface, palavra inglesa para “superfície”.

Há um detalhe importante: desenhamos pensando em linhas e colunas, mas a memória é como uma fita longa, com um byte depois do outro. Portanto, a Surface guarda largura, altura e a sequência de bytes. Ela também guarda o stride.

fn offset(&self, x: i32, y: i32) -> Option<usize> {
    if x < 0 || y < 0
        || x >= self.width as i32
        || y >= self.height as i32 {
        return None;
    }

    Some(y as usize * self.stride + x as usize * 4)
}

pub fn put_pixel(&mut self, x: i32, y: i32, color: Color) {
    let Some(offset) = self.offset(x, y) else { return };

    self.pixels[offset..offset + 4]
        .copy_from_slice(&[color.r, color.g, color.b, color.a]);
}

A fórmula y × stride + x × 4 faz duas viagens: primeiro pula y linhas completas; depois avança x pixels dentro da linha. O × 4 existe porque cada pixel tem quatro bytes.

Antes de acessar a memória, o código pergunta se x e y estão dentro da folha. Se estiverem fora, retorna None e não desenha. Essa proteção também é chamada de clipping: ignorar a parte do desenho que cairia fora da área permitida.

Se pintarmos com tinta sólida, a nova cor substitui a antiga. Mas pense em uma folha laranja transparente sobre uma mesa azul: vemos um pouco do laranja e um pouco do azul. O computador simula essa combinação calculando uma nova cor.

Esse cálculo se chama alpha blending: “mistura usando o alpha”. Chamaremos a cor que chega de origem e a cor que já estava no pixel de destino. Com alpha de 50%, pegamos metade de cada uma:

resultado = origem × alpha + destino × (1 − alpha)

Se um canal vermelho de valor 200, com alpha de 50%, cobre um fundo preto de valor 0, o resultado fica perto de 100: metade de 200 mais metade de 0. Repetimos a mesma conta separadamente para vermelho, verde e azul.

pub fn blend_pixel(&mut self, x: i32, y: i32, source: Color) {
    let Some(destination) = self.pixel(x, y) else { return };
    let alpha = source.a as u32;

    let mix = |src: u8, dst: u8| {
        ((src as u32 * alpha
          + dst as u32 * (255 - alpha) + 127) / 255) as u8
    };

    self.put_pixel(x, y, Color::rgba(
        mix(source.r, destination.r),
        mix(source.g, destination.g),
        mix(source.b, destination.b),
        255,
    ));
}

Imagine limpar a tela, desenhar o painel, depois o texto e por último o botão diretamente na imagem visível. Se o monitor atualizar no meio, o usuário verá um frame incompleto. Double buffering separa construção e apresentação.

Quando a imagem é trocada enquanto o monitor ainda está percorrendo a tela, a parte superior pode pertencer ao quadro antigo e a inferior ao novo. Surge uma “quebra” horizontal chamada tearing. VSync é a tentativa de sincronizar a troca com o instante em que o monitor terminou um ciclo. Triple buffering usa uma terceira imagem de reserva; pode dar mais liberdade ao programa, mas consome mais memória.

Nem toda plataforma expõe uma “troca de ponteiros” literal. No Wayland, o compositor envia wl_buffer.release quando terminou de usar um buffer. Nosso código mantém dois slots: desenha somente num slot livre, marca-o como ocupado depois do commit e só o reutiliza após esse evento. O conceito permanece: nunca escrever na imagem que outra camada ainda está lendo.

Já sabemos acender um pixel, mas seria cansativo repetir milhares de vezes “ande por estas linhas e colunas” sempre que quiséssemos um botão. Precisamos de uma camada que transforme pedidos humanos, como “desenhe um retângulo laranja”, em muitos pixels.

Chamaremos esse ajudante de Painter, “pintor” em inglês. Ele não é uma ferramenta pronta da linguagem: é uma estrutura criada no nosso projeto. Recebe a Surface, nossa folha na memória, e oferece funções como preencher retângulo, desenhar borda e escrever letras.

pub fn fill_rect(&mut self, rect: Rect, color: Color) {
    let Some(rect) = rect.intersect(self.clip) else { return };

    for y in rect.y..rect.y + rect.height {
        for x in rect.x..rect.x + rect.width {
            self.surface.blend_pixel(x, y, color);
        }
    }
}

pub fn stroke_rect(&mut self, r: Rect, t: i32, color: Color) {
    self.fill_rect(Rect::new(r.x, r.y, r.width, t), color);
    self.fill_rect(Rect::new(r.x, r.y + r.height - t, r.width, t), color);
    self.fill_rect(Rect::new(r.x, r.y, t, r.height), color);
    self.fill_rect(Rect::new(r.x + r.width - t, r.y, t, r.height), color);
}

Também podemos copiar uma imagem pronta para nossa folha. Essa cópia em bloco costuma ser chamada de blit. Carregar o arquivo implica abrir, identificar, decodificar e validar bytes; esse caminho conversa com Como um computador sabe qual programa abre um arquivo? e Construindo um sistema de arquivos do zero.

Texto não é uma sequência de retângulos comuns

Nossa fonte bitmap 5 × 7 associa cada caractere a sete linhas de bits. Bit ligado pinta um bloco; bit desligado deixa o fundo aparecer.

// Letra A em uma grade de 5 colunas × 7 linhas
'A' => [
    0b01110,
    0b10001,
    0b10001,
    0b11111,
    0b10001,
    0b10001,
    0b10001,
]

Isso ensina a passagem de símbolo para pixels, mas não resolve texto real: Unicode, fallback de fontes, ligaturas, kerning, shaping, escrita da direita para a esquerda e hinting ficam fora desta versão.

• Tela: posição global no desktop.
• Janela: posição dentro da área cliente.
• Widget: posição relativa ao pai.
• Local: posição dentro do próprio componente.

Se o hit testing comparar um ponto da tela com um retângulo local, o botão funcionará apenas por coincidência. Transformações explícitas tornam o sistema previsível.

Widget é o nome tradicional para uma peça da interface gráfica. Um botão é um widget. Um texto é outro. Um painel que agrupa os dois também pode ser um widget. Pense em peças de montar: cada uma tem aparência e função próprias, mas todas sabem se encaixar no mesmo sistema.

Cada peça precisa responder a quatro perguntas: “qual tamanho você deseja?”, “onde você ficará?”, “o que fará quando receber uma entrada?” e “como será desenhada?”. No código, reunimos essas perguntas em um trait, um contrato que tipos diferentes podem cumprir.

pub trait Widget {
    fn measure(&self, constraints: Constraints) -> Size;
    fn layout(&mut self, bounds: Rect);
    fn bounds(&self) -> Rect;
    fn event(&mut self, event: Event) -> bool;
    fn paint(&self, painter: &mut Painter<'_>);
}

A janela guarda essas peças numa estrutura parecida com uma árvore: o painel é o “pai”; texto e botão são seus “filhos”. Como essa árvore continua guardada na memória entre uma ação e outra, o modelo é chamado de retained mode, ou “modo retido”. No immediate mode, ou “modo imediato”, o programa descreve novamente a interface a cada quadro. Para nosso projeto, guardar a árvore deixa mais fácil acompanhar o estado de cada botão.

Layout é o processo de calcular tamanho e posição. Imagine organizar livros numa prateleira: cada livro tem uma largura desejada, mas todos precisam caber no espaço real. Na GUI, o elemento pai informa ao filho um mínimo e um máximo; essas regras são chamadas de constraints, ou restrições.

O filho calcula o tamanho que gostaria de ter e o ajusta aos limites. Um texto considera quantas letras possui; um botão soma a largura do texto, o espaço interno e a borda.

pub struct Constraints {
    pub min: Size,
    pub max: Size,
}

pub fn constrain(self, size: Size) -> Size {
    Size {
        width: size.width.clamp(self.min.width, self.max.width),
        height: size.height.clamp(self.min.height, self.max.height),
    }
}

No layout vertical, y começa no topo; cada filho recebe um retângulo e y avança por altura + gap. No horizontal, o raciocínio se repete no eixo x. Redimensionar a janela executa medida e posicionamento novamente.

O sistema informa algo como “o ponteiro está em x = 312, y = 224”. Ele não conhece o botão que inventamos. Nossa GUI precisa fazer uma pergunta geométrica: qual retângulo visível contém esse ponto? Essa procura recebe o nome de hit testing, ou “teste de acerto”.

Começamos pela janela, descemos para o painel e então verificamos seus filhos. Quando elementos se sobrepõem, testamos primeiro o que foi desenhado por último, pois ele está visualmente na frente.

pub fn contains(self, point: Point) -> bool {
    point.x >= self.x
        && point.y >= self.y
        && point.x < self.x + self.width
        && point.y < self.y + self.height
}

As bordas direita e inferior são exclusivas. Assim, dois retângulos adjacentes não reivindicam o mesmo pixel.

O dispositivo informa que um botão físico desceu ou subiu. A GUI cria estados semânticos:

PointerDown dentro:
    pressed_inside = true
    state = Pressed

PointerUp:
    click = pressed_inside && cursor_ainda_esta_dentro
    pressed_inside = false
    state = Hover ou Normal

Pressionar dentro, arrastar para fora e soltar normalmente cancela. Essa regra simples mostra por que click é um gesto interpretado, não um único pacote vindo do hardware.

Foco identifica o widget que receberá teclas. Tab avança pela ordem de foco; Shift+Tab retorna. Enter ou Espaço ativa o botão focado. O contorno em ciano torna esse estado observável.

Pixels não carregam significado. Um leitor de tela não deveria adivinhar que um retângulo laranja com texto é clicável. Por isso existe uma árvore de acessibilidade paralela à visual.

AccessibilityNode {
    role: "button",
    name: "EXECUTAR",
    focused: true,
    disabled: false,
    action: Some("activate"),
}

A Janela UI representa esses dados, mas não implementa adaptadores para UI Automation, NSAccessibility, AT-SPI ou equivalentes. Declarar o limite evita confundir um modelo didático com suporte assistivo completo.

Depois de mostrar a primeira imagem, o programa não pode simplesmente terminar. Ele precisa continuar esperando pelo próximo movimento, tecla, redimensionamento ou pedido para fechar. Essa repetição é o event loop, em português, “ciclo de eventos”.

Uma volta funciona assim: esperar uma ocorrência; encaminhar ao elemento correto; atualizar o estado; desenhar uma nova imagem se necessário; e apresentar essa imagem. Depois, tudo começa novamente.

while window.is_open() {
    let events = window.poll_events();

    for event in events {
        app.dispatch(event);
    }

    if app.needs_redraw() {
        app.layout();
        app.paint(&mut back_buffer);
        window.present(back_buffer.bytes());
    }
}

Esperar enquanto não há eventos reduz CPU e energia. Animações e temporizadores pedem novos quadros deliberadamente. Nosso laço didático faz uma pausa curta entre voltas e só reconstrói a interface quando alguma ação a marcou para redesenho.

Imagine que o botão era azul e, ao receber o mouse, deve ficar laranja. Os pixels guardados ainda mostram o azul. Dizemos então que aquela imagem foi invalidada: o estado mudou e o desenho antigo deixou de representar a verdade. Invalidar significa apenas marcar “precisa redesenhar”.

A estratégia mais simples é marcar a janela inteira e reconstruir todos os pixels. Chamaremos isso de redesenho total. É fácil de entender e difícil de errar, por isso o código final começa assim.

Uma otimização possível é marcar somente o retângulo onde houve mudança. Essa região é chamada de dirty rectangle, literalmente “retângulo sujo”: não está sujo de verdade; apenas contém pixels desatualizados. Reconstruir somente essas regiões é o redesenho parcial.

No exemplo, redesenhar tudo visita 256.000 pixels; redesenhar apenas a região alterada visita 8.400. Porém, “parcial” não significa simplesmente pintar o botão outra vez. Se ele tem transparência, sua cor depende do painel que está atrás. Precisamos primeiro reconstruir o pedaço correspondente do fundo e depois pintar o botão por cima. Quando várias áreas mudam, podemos juntá-las. Caso contrário, ficam rastros da imagem antiga.

Nossa Surface contém apenas o interior de uma janela. Mas o monitor precisa mostrar, ao mesmo tempo, papel de parede, barra do sistema, cursor e outras aplicações. O componente que reúne essas imagens em camadas é chamado de compositor.

A CPU calcula posições, descobre qual elemento recebeu a entrada e transforma formas em pixels. Nosso módulo wayland.rs copia essa imagem para um buffer compartilhado, conecta o buffer a uma wl_surface e confirma a atualização com commit. O compositor Wayland combina nossa superfície com as demais janelas e envia a cena pronta ao monitor.

A GPU pode ajudar a mover e combinar essas imagens. O driver é o software que conversa com o hardware gráfico. A leitura contínua da imagem final para alimentar o monitor é chamada de scanout. Esses detalhes variam entre plataformas; o importante é separar nosso desenho da composição do desktop. Para compreender como instruções e memória são processadas pela CPU, veja Como uma CPU funciona por dentro.

janela-ui/
├── Cargo.toml
├── README.md
├── src/
│   ├── main.rs
│   ├── wayland.rs
│   ├── lib.rs
│   ├── app.rs
│   ├── color.rs
│   ├── geometry.rs
│   ├── surface.rs
│   ├── painter.rs
│   ├── layout.rs
│   ├── event.rs
│   ├── widget.rs
│   └── widgets/
│       ├── mod.rs
│       ├── panel.rs
│       ├── label.rs
│       └── button.rs
└── tests/
    ├── pixels.rs
    ├── layout.rs
    ├── hit_test.rs
    └── events.rs

1. O estado da aplicação

pub struct App {
    panel: Panel,
    label: Label,
    button: Button,
    dirty: bool,
}

O clique incrementa o contador do botão, troca “PRONTO” por “EXECUTADO!” e muda a cor do painel. A aplicação coordena componentes; ela não desenha pixels diretamente.

2. Layout independente da janela nativa

pub fn layout(&mut self, width: i32, height: i32) {
    self.panel.layout(Rect::new(0, 0, width, height));

    let constraints = Constraints::loose(width - 96, height - 96);
    let label_size = self.label.measure(constraints);
    let button_size = self.button.measure(constraints);

    self.label.layout(Rect::new(48, 70,
        label_size.width, label_size.height));
    self.button.layout(Rect::new(48, 120,
        button_size.width.max(180), button_size.height));
}

3. Pintura respeita a ordem da árvore

pub fn paint(&mut self, surface: &mut Surface) {
    if !self.dirty { return; }

    let mut painter = Painter::new(surface);
    self.panel.paint(&mut painter);
    self.label.paint(&mut painter);
    self.button.paint(&mut painter);

    self.dirty = false;
}

O painel vem primeiro, portanto funciona como fundo. Label e botão aparecem por cima. Inverter a ordem cobriria os filhos.

4. Nós mesmos montamos a janela no Wayland

Wayland funciona como uma conversa entre objetos. Primeiro conectamos ao compositor. Em seguida, o registry, ou registro, anuncia quais recursos existem. Pedimos um wl_compositor para criar a superfície, um wl_shm para compartilhar pixels e um xdg_wm_base para transformar a superfície numa janela comum do desktop.

let connection = Connection::connect_to_env()?;
let display = connection.display();

// O registro anunciará compositor, memória, entrada e xdg-shell.
display.get_registry(&queue_handle, Globals);

Memória compartilhada significa que aplicação e compositor têm acesso ao mesmo bloco de bytes. Criamos dois arquivos de memória, um wl_shm_pool para cada um e recortamos dois wl_buffer de 640 × 400 pixels. Cada pixel usa o formato ARGB8888.

let pool = shm.create_pool(file.as_fd(), tamanho, qh, NoopIgnore);
let buffer = pool.create_buffer(
    0, 640, 400, 640 * 4,
    wl_shm::Format::Argb8888,
    qh, BufferHandler(slot_index),
);

Depois de desenhar, copiamos os pixels para um slot livre, anexamos o buffer à superfície e fazemos commit. Esse último pedido significa: “a nova versão da minha superfície está pronta”.

arquivo.write_all(&surface.to_bgra8888())?;
wl_surface.attach(Some(&buffer), 0, 0);
wl_surface.damage(0, 0, 640, 400);
wl_surface.commit();

Quando chega wl_buffer.release, marcamos o slot como livre. Essa confirmação é indispensável: memória compartilhada não autoriza a aplicação a alterar bytes enquanto o compositor ainda os utiliza.

Testes visuais manuais são úteis, mas não provam cada regra. Como a surface é um vetor, podemos testar o byte exato. Como hit testing usa retângulos, podemos testar bordas. Como o botão possui uma máquina de estados, podemos enviar eventos sintéticos.

#[test]
fn alpha_de_cinquenta_porcento_mistura_as_cores() {
    let mut surface = Surface::new(
        1, 1, Color::rgba(0, 0, 0, 255)
    );

    surface.blend_pixel(
        0, 0, Color::rgba(200, 100, 40, 128)
    );

    assert_eq!(
        surface.pixel(0, 0),
        Some(Color::rgba(100, 50, 20, 255))
    );
}

#[test]
fn clique_exige_press_e_release_dentro() {
    let mut button = Button::new("EXECUTAR");
    button.layout(Rect::new(10, 10, 120, 46));

    button.event(PointerDown { position: Point::new(20, 20) });
    assert_eq!(button.state(), ButtonState::Pressed);

    button.event(PointerUp { position: Point::new(20, 20) });
    assert_eq!(button.clicks, 1);
}

Um passo adicional seria guardar pequenas surfaces conhecidas como snapshots. Se um algoritmo alterar pixels inesperados, a comparação denuncia a regressão.

Também faltam clipboard, drag and drop, menus, múltiplas janelas, internacionalização, animações, temas, cursores, seleção de texto e integração refinada com o compositor. Agora, porém, cada uma dessas palavras aponta para um problema concreto, não para uma caixa-preta.

Quando o cursor entra no botão, o Wayland envia a posição do ponteiro. A procura pelo alvo encontra a peça da interface que contém aquele ponto. O botão muda para o estado “mouse por cima” e avisa que o desenho antigo não vale mais. O ciclo de eventos pede uma nova pintura. Nosso estojo de desenho transforma o botão em retângulos, bordas e letras. A folha guardada na memória recebe as receitas RGBA de cada pixel. Por fim, anexamos esse buffer à superfície e o compositor combina nossa janela com as outras.