From 373f842bef0575054e1ce298ff9ef8c4420e35e9 Mon Sep 17 00:00:00 2001 From: bQUARKz Date: Mon, 15 Jun 2026 12:15:57 +0100 Subject: [PATCH] align render worker agenda direction --- ...GD-0043-real-render-worker-establishment.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/discussion/workflow/agendas/AGD-0043-real-render-worker-establishment.md b/discussion/workflow/agendas/AGD-0043-real-render-worker-establishment.md index e9b84cb2..af4d6edd 100644 --- a/discussion/workflow/agendas/AGD-0043-real-render-worker-establishment.md +++ b/discussion/workflow/agendas/AGD-0043-real-render-worker-establishment.md @@ -167,9 +167,9 @@ O host desktop pode ser a primeira integracao concreta, mas nao deve ser o unico **Pergunta:** Quem chama present: worker, host event loop, ou display cadence service? -**Sugestao:** no primeiro corte, o worker deve produzir/publish uma superficie pronta e notificar host invalidation; o host event loop continua sendo autoridade de apresentacao da janela nativa. O "repeat ultimo frame valido" deve ser modelado no controller/telemetry como comportamento de consumo/cadence, mas o swap/window present concreto deve respeitar o host. +**Sugestao:** no primeiro corte, o worker deve produzir/publish uma superficie pronta como buffer RGBA8888 owned, por exemplo `OwnedRgba8888Frame`. O host event loop continua sendo autoridade de apresentacao da janela nativa. O "repeat ultimo frame valido" deve repetir o ultimo buffer publicado, nao recompor nem exigir que o worker conheca a API nativa de janela/swap. -**Motivo:** winit/pixels e plataformas graficas frequentemente tem afinidade com thread/event loop. Colocar o swap real dentro do worker pode funcionar em alguns hosts e quebrar portabilidade. O contrato importante e que a VM nao bloqueie e que o host tenha uma superficie publicada coerente. +**Motivo:** RGBA8888 ja e o formato logico canonico nas specs. Um frame owned com `FrameId`, ownership/epoch, largura, altura, stride e pixels RGBA8888 deixa o contrato testavel sem janela e evita acoplamento a winit/pixels, SDL, swapchain ou textura nativa. Colocar o swap real dentro do worker pode funcionar em alguns hosts e quebrar portabilidade. O contrato importante e que a VM nao bloqueie e que o host tenha uma superficie publicada coerente. ### 5. Como o worker recebe recursos read-only? @@ -219,5 +219,19 @@ Esta agenda pode virar decision quando tivermos: ## Discussion - 2026-06-06: Agenda criada dentro da `DSC-0042` para separar worker real da preparacao de fronteira discutida em `AGD-0042`. +- 2026-06-15: Apos a conclusao dos planos `PLN-0098` a `PLN-0109`, a direcao da agenda foi alinhada em torno da Opcao C: controller em `prometeu-system`, handoff single-slot thread-safe, backend fake/local primeiro, e publicacao de frame owned RGBA8888 antes da integracao desktop concreta. ## Resolution + +Direcao proposta para decisao: + +- `RenderManager` continua como autoridade de policy, ownership/epoch, latest-wins e telemetry; +- o worker controller contratual deve viver em `prometeu-system`; +- traits compartilhadas minimas podem viver em `prometeu-hal`; +- o handoff real deve ser single-slot latest-wins com sincronizacao explicita, inicialmente `Mutex> + Condvar`; +- o worker separa `pending` de `in_flight` e checa stop/ownership/epoch antes de publicar; +- o worker publica um `OwnedRgba8888Frame` ou equivalente, contendo frame id, owner/epoch, dimensoes, stride e pixels RGBA8888 owned; +- o host event loop faz o upload/present nativo a partir do ultimo frame publicado; +- o primeiro backend deve ser fake/local para provar contrato e concorrencia sem janela; +- a integracao desktop concreta vem depois, usando a mesma trait/backend contract; +- testes devem usar barreiras/condvars para provar ausencia de bloqueio da VM, latest-wins, stale discard, shutdown bounded e telemetry.