[OpenVIP-devel] algoritmy

[Vaclav S. <vac...@ma...>]

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