Programação de GUI em Modo Imediato

Artigo original ↗ Discussão no Hacker News ↗

Frameworks de GUI em modo imediato, como Dear ImGui e egui, prometem código de UI mais simples e linear ao redesenhar a interface a cada frame e evitar a instalação explícita de manipuladores de eventos. Os comentaristas contrastam isso com toolkits tradicionais de modo retido (Qt, widgets nativos do SO, layouts web/CSS), argumentando que, embora o modo imediato seja excelente para ferramentas dentro do engine, UIs de depuração e alguns apps desktop, ele enfrenta dificuldades com layouts complexos, integração com a plataforma, acessibilidade e uso de energia, a menos que sistemas extras de estado e layout sejam efetivamente reconstruídos. Vários observam que sistemas “declarativos” modernos como React ficam em algum ponto intermediário, e que, na prática, a escolha certa depende menos da pureza do paradigma e mais da maturidade das ferramentas, das necessidades de desempenho e de quanta complexidade e polimento da UI os usuários finais esperam.

Visão geral: GUIs de modo imediato vs. modo retido

  • Modo imediato: a UI é descrita a cada frame em código linear (por exemplo, if Button(...) { ... }). Não há objetos explícitos de widgets nem manipuladores de eventos instalados no código do usuário; o estado muitas vezes fica oculto dentro do framework.
  • Modo retido: a UI é uma árvore de widgets/objetos com seu próprio estado e callbacks; o toolkit “possui” o loop de eventos e redesenha conforme necessário.
  • Vários comentaristas enfatizam que a distinção diz respeito principalmente à API pública, e não a se o estado é retido internamente.

Loop de eventos, fluxo de controle e depuração

  • Defensores gostam de ter um único loop principal e um fluxo de controle linear, mais fácil de depurar, em vez de callbacks espalhados.
  • Críticos argumentam que você nunca realmente “se livra” do loop de eventos; o SO ainda conduz os eventos, e a maioria dos backends IMGUI espera um padrão tradicional de loop de eventos.
  • Alguns veem a simplificação do fluxo de controle como algo que acelera o desenvolvimento, especialmente para desenvolvedores que não gostam de programação tradicional de UI.

Desempenho, bateria e redesenho

  • Céticos: redesenho constante da tela inteira e layout por frame podem desperdiçar CPU e bateria, especialmente em laptops e dispositivos móveis. Foram dados exemplos de ferramentas IMGUI consumindo CPU perceptível em repouso.
  • Outros contra-argumentam que:
    • Você pode bloquear em eventos e repintar apenas quando houver interação.
    • Frameworks IMGUI podem rastrear “retângulos interativos”, regiões sujas e cachear estado.
    • Algumas bibliotecas já repintam apenas quando há mudanças, embora existam issues e PRs abertos sobre “modos de economia de energia”.
  • Permanece a discordância sobre se essas otimizações são inerentes ou apenas complexidade extra empurrada para o autor da aplicação/framework.

UIs complexas, layout e estado

  • Experiências pró-IMGUI vindas de ferramentas de desenvolvimento de jogos: editores complexos, inspetores, perfis e UIs de depuração foram construídos com sucesso, beneficiando-se da integração estreita com a lógica do engine.
  • Críticos relatam dor ao sair de “depuradores improvisados” para ferramentas completas: as pessoas passam a emular modo retido, mantendo muito estado e lógica de layout manualmente, o que leva a código bagunçado.
  • Layout é um grande ponto de tensão:
    • Modo imediato é visto como ótimo para layouts simples e posicionamento manual.
    • Restrições responsivas e de múltiplas passagens (por exemplo, quebra de texto, centralização de vários widgets, redimensionamento dinâmico) são mais difíceis; algumas bibliotecas (por exemplo, certos IMGUIs em Rust) têm limitações notáveis.
    • Outros descrevem algoritmos de layout de múltiplas passagens funcionando bem em IMGUI; o desafio é o desempenho e a necessidade de refazer o layout a cada frame.

Casos de uso e adequação

  • Forte encaixe:
    • Ferramentas dentro do engine, overlays de depuração, editores de jogos, ferramentas internas simples, apps com muito gráfico em que já existe um loop de renderização.
  • Menor adequação / ceticismo:
    • Aplicativos desktop para usuários finais, onde se espera aparência nativa, baixo uso de CPU em repouso e forte integração com a plataforma.
    • Aplicativos móveis, onde energia, desempenho, convenções da plataforma e acessibilidade são críticos; vários recomendam usar toolkits nativos ou apoiados por nativo em vez disso.

Relação com UIs web/estilo React

  • Alguns veem React, Flutter, SwiftUI, Streamlit etc. como “semelhantes ao modo imediato” porque as UIs são redeclaradas a cada renderização; o VDOM do React é descrito como “imediato por cima de retido”.
  • Outros observam diferenças no fluxo de eventos e no gerenciamento de estado, mas em geral concordam que há sobreposição conceitual.

Acessibilidade, completude e reinvenção

  • Críticos enfatizam que apps sérios precisam de localização, acessibilidade e widgets ricos; reconstruir tudo isso em IMGUI é um esforço grande e corre o risco de repetir erros já resolvidos em toolkits maduros.
  • Existem exemplos de frameworks IMGUI integrando camadas de acessibilidade, mostrando que é possível, mas não comum.
  • Vários concluem que ambos os paradigmas são ferramentas; a principal vantagem do IMGUI é a produtividade do desenvolvedor para certas classes de apps, não uma substituição universal para GUIs retidas.