Feature request: reuse the browser, server and page across renderStill calls
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- react, typescript
Direzione di ricerca
Start by reading the implementations and call paths for renderStill, renderFrames, and renderMedia, especially where they start the static server, create the browser context and page, and close them. Compare the current shared-browser lifecycle with the requested caller-owned browser and multi-frame workflow; clarify the API and output-pattern behavior before implementation. Done means callers can control browser lifetime and render multiple frames without repeating page setup.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
We render a lot of stills (thumbnails and frame checks), and each renderStill call has a fixed setup cost. It would help to be able to pass in a browser we own, like Remotion's puppeteerInstance, or even better to render several frames on one loaded page.
To be fair, renderStill does already reuse the shared browser: the same Browser instance served 10 calls in a row when I checked. But each call still starts a new static server, opens a new context and page, loads the bundle (networkidle), waits for __RENDIV_LOADED__ plus a fixed 100 ms, and then closes the page. For a trivial 320x180 composition that's about 0.8 s per still on my machine (Windows 11), and nearly all of it is setup.
Two things would help:
- a
browseroption onrenderStill(and onrenderFramesandrenderMediafor consistency), so callers control the browser's lifetime explicitly instead of relying on the module-level singleton andcloseBrowser(); - a way to render several frames in one call (e.g.
frames: number[]with an output pattern), so the server and page are only set up once.
- Lingua principale
- TypeScript
- Stelle
- 159
- Fork
- 32
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di thecodacus/rendiv
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
thecodacus/rendiv#17 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
thecodacus/rendiv#16 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
thecodacus/rendiv#15 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
thecodacus/rendiv#24 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
thecodacus/rendiv#22 ·
Tutte le issue di thecodacus/rendiv
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
binding:python bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
coollabsio/orbit#72 ·
I maintainer di solito rispondono entro 1 giorno
-
Bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
I maintainer di solito rispondono entro 1 giorno
-
bug needs-triage potential-regression
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
aws/aws-sdk-js-v3#8408 ·
I maintainer di solito rispondono entro 1 giorno