|
From: Vaclav S. <vac...@ma...> - 2002-04-21 21:34:44
|
Cau,
nahral jsem na web popis toho algoritmu:
http://openvip.sf.net/internal/notes/architecture.html#scheduler
http://openvip.sf.net/internal/notes/algorithms.html
Vyhody pristupu "plugin si vstupni data obstara sam" (1):
- *trosku* mensi overhead=20
- ??? (Michale?)
Nevyhody tehoz:
- *znemoznuje* paralelizmus. Pokud pouzijeme tenhle pristup, tak
se nam proste paralelizovat system nepodari
- problem se seekovanim v audiu, obecne hodne seekovani, muselo=20
by se resit pomoci ad-hoc cache (vubec to neresi ten problem s=20
porty!)
Vyhody separace pluginu a planovace:
- je mozne vymenit planovac a pouzivat stare pluginy (stabilni API)
- dusledek: lze pro zacatek mi jednoduchy planovac a vylepsovat ho
postupne v pripade potreby
- "cisty" design: separuje nesouvisejici ulohy (poradi renderovani,=20
renderovani konkretniho efektu) do 2 nezavislych entit
- lze v pripade potreby (cti: extremni pouziti site) pouzit=20
prizpusobeny planovac; ten globalni planovac navic resi problemy
se seekovanim bez toho, ze bychom museli pridavat cache na
bottlenecky (cache je implementacni detail planovace)
Takze muj navrh je tohle: pouzit API s oddelenym planovacem a moduly=20
(tak, jak jsme se o tom v utery bavili), ale zatim ten slozity=20
planovac neimplementovat a pouzit jednoduchy "rekurzivni", chovajici=20
se stejne jako (1).=20
Vasek
|