Hlavní navigace

Názor ke zprávičce Nadějné emulátory terminálu od robotron - Tenhle clanek na me hluboce zapusobil a to...

  • 25. 1. 2017 1:56

    robotron (neregistrovaný) 80.250.30.---

    Tenhle clanek na me hluboce zapusobil a to v mnoha smerech: od vazneho zamysleni az po ruzne odstiny humoru. Patrim k lidem, co terminaly hodne trapi a predevsim me zajima zatez CPU a vubec, kolik toho muzu do terminalu pustit, aniz by zdrzoval || varil pocitac. Mam totiz ve zvyku poustet spoustu ruznejch numerickejch a RT ridicich uloh, kde se hrnou spousty vetsinou cisel ale i jinejch podobnejch hovadin v mnoha terminalech. Zda se to (nekterejm lidem) jako desna pitomost, mit na pocitaci bezici Matrix, ale vetsinou oko-mozek celkem zvlada vyzobavat podstatny veci, jako "jak moc signal sumi", "kolik desetinnejch mist je stabilnich", "jak casto se objevi v pravidelnem vzoru poryv" apod. Bezne na 100Hz vzorkovacky/1 radek o 120 znacich treba. Tolik k uvodni motivaci.

    Zatim pouzivam xterm a rxvt. Zatez je nekdy nechutna. Podeziram je (do zdrojaku jsem ale nekoukal), ze se snazi vsechno, co prijde, vykreslit. Opravte me, pokud se pletu a je i v techto dinosaurech nejaka VNC/fps logika. (Pozn.: pouzivam X11 s vypnutym AA u fontu, pro vsechny aplikace, nejen terminaly.)

    Co me velmi udivuje, je: pro uživatele, co potřebují vypsat rychle spoustu znaků. Je akcelerován na GPU; kouknul jsem na uvodni stranku a tam to veru zduraznuji. Chapete nekdo, k cemu muze bejt takova akcelerace dobra? Ja ne.

    Dle meho -- zcela laickeho a cetbou zdrojaku terminalu nezatizeneho -- nazoru je otazka svizneho terminalu dvoji: zvladat pozirat vstup a pocitat z toho, jak vypada aktualni obraz (tj. umisteni znaku a ruzna rolovani); dale pak, aktualni obraz vykreslit. Pozirani vstupu je podmnozinou ulohy textoveho editoru, vyhoda je, ze pracuje s 1B/1znak. Nevyhoda, ze v extremnich pripadech meho typu to naky prase muze zahlcovat i >10KB/s (porad ale na dnesni dobu celkem snesitelny toky). Myslim, ze v tehle uloze se ten hlavni vypocetni vykon nepali.

    Druha uloha je: zname matici znaku v danem okamziku a chceme ji nakreslit. Tahle uloha z principu nemusi/nemuze fungovat na snimkove frekvenci vyssi, nez je snimkova frekvence monitoru. Pri rozmerech 150x100 @75fps jsme na 1MB/s (prakticka rychlost nepretaktovany ISA sbernice, pro srovnani). Postarsi X11 terminal vzdalene pres 10Mb/s Ethernet uz se nechyta.

    Jak to vykreslit? V klasicky logice ne-AA fontu podle me nemuze bejt lepsi cesty, nez klasicka 2D akcelerace se spritama nahranejma v karte. U AA fontu a subpixel renderingu zdanlive zacina uplne jina hra -- ale je opravdu o tolik jina? Pro obecnej proporcni text, umistenej na libovolne x,y souradnici a treba jeste s kerningem, skutecne problem. Ale terminal z principu ma znaky v pevnem sachovnicovem rastru, bez kerningu a i kdyby doslo na RGB subpixel rendering, tak zbyvaji pouze 3 mozne posuvy okna terminalu vuci RGB masce -- procez jsem presvedcen, ze predpocitat AA znaku, od kazdeho 3 varianty podle posuvu vuci RGB a je hotovo, zbytek se muze sazet primo blitterem.

    Je tato uvaha zcestna? Opomnel jsem neco?