Agenda - [PERF] Host Desktop Frame Pacing and Presentation

Problema

O host desktop ainda roda em modo agressivo de polling e apresentacao continua.

Hoje o loop usa ControlFlow::Poll, pede redraw incondicionalmente e converte o framebuffer inteiro de RGB565 para RGBA8 a cada RedrawRequested, mesmo quando nao ha novo frame logico.

Dor

CPU fica ocupada sem ganho visual.
port de referencia no desktop mascara problemas de pacing em hardware barato.
a conta de energia/temperatura piora mesmo quando a VM esta ociosa.

Hotspots Atuais

Alvo da Discussao

Fechar uma politica de pacing/apresentacao host-driven que nao desperdice CPU quando nao existe frame novo.

O Que Precisa Ser Definido

Gatilho de redraw. Decidir se redraw acontece:
- apenas com logical frame pronto;
- por deadline de vsync;
- por dirty flag do front buffer;
- por evento externo relevante.
Politica do event loop. Decidir entre:
- Wait;
- WaitUntil;
- Poll apenas em modo debug/profiling.
Conversao de framebuffer. Definir se a conversao RGB565 -> RGBA8:
- continua full-frame;
- passa a ser dirty-region;
- sai da CPU e vai para shader/path especifico do host.
Modo ocioso. Delimitar comportamento quando VM esta pausada, em breakpoint ou sem cart.

Open Questions de Arquitetura

O host desktop deve ser referencia conservadora de energia ou apenas shell de desenvolvimento? R: O desktop eh shell de desenvolvimento, mas pode tb ser usado para jogar em um pc. Deve oferecer controle de energia como um handheld, especialmente para desenvolvimento.
O runtime precisa expor um sinal explicito de "novo frame disponivel" para o host? R: Atualmente fazemos o swap do buffer somente quando o frame logico eh pronto, esse eh o "ponto de entrada" para o host. Eh ali que a conversao de RGB565 -> RGBA8 pode ser realizada e mostrada. Se o host precisar saber quando o frame eh pronto, pode ser exposto por um sinal explicito.
Existe necessidade real de redraw continuo quando o overlay esta desligado? R: Nao

Perguntas em Aberto

Nenhuma. As perguntas de arquitetura desta agenda foram respondidas e o tema esta pronto para cristalizacao em decisao.

Resolucao

A agenda fecha com a direcao de que o host desktop nao deve manter redraw continuo por padrao. O host deve operar com pacing orientado por frame logico pronto e por eventos externos relevantes, preservando um comportamento energeticamente conservador sem perder utilidade como shell de desenvolvimento. Se o host precisar consumir esse momento de forma explicita, o runtime pode expor um sinal canonico de "novo frame disponivel" no ponto em que o frame logico eh concluido.

Dependencias

../specs/01-time-model-and-cycles.md
../specs/10-debug-inspection-and-profiling.md
../specs/11-portability-and-cross-platform-execution.md

Criterio de Saida Desta Agenda

Pode virar PR quando houver decisao escrita sobre:

politica de control flow do host;
criterio canonico de redraw;
estrategia de conversao/apresentacao de framebuffer;
comportamento de idle/pause/debug.

3.7 KiB Raw Blame History