Názory k článku Operace s framebufferem na Raspberry Pi (dokončení)

Má to pěkně udělané, dík za odkaz. Už dlouho přemýšlím, že bych něco podobného udělal interaktivně v JS (i s těmi mezivýsledky), ale chtělo by to nějaké nakopnutí :-) [podobné stránky už existují, ale nejdou úplně do detailů]

Ahoj Pavle,

skvělé čtení, jako obvykle. Jen chci upozornit, že od tohoto týdne už RPi2 umí i "pravé" OpenGL, takže se mu můžeš věnovat, jak vyčerpáš GLES :-)

Ahoj Petře,

díky za info! To je velmi dobrá zpráva, protože SW rendering hodně brzdil například některé hry nebo všechna demíčka z LOVE (to mě asi štvalo víc). Já už tady kdysi "klasické" OpenGL probral, ale opakování matka moudrosti :-) GLES ale určitě nezapadne, dneska je to na prakticky každém tabletu a smartphonu, možnosti urychlení mnoha algoritmů jsou značné.

To je na jednu stranu pravda, na stranu druhou to skutečně cílím hlavně na RPi a to proto, že mě to jinak lidi omlátí o hlavu stylem "ty ......, na 2d grafiku je tady [cairo, agg, SDL, Allegro, Qt, ...], na co framebuffer", kdežto na RPi je to podle mě jeden z nejlepších přístupů, který přesně odpovídá tomu, proč ten počítač vlastně vznikl (měl to být návrat ke kořenům, nakonec se na to nabalilo zase mnoho mnohdy zbytečných mezivrstev mezi programátorem a HW).

OpenVG vs. GLES - tady mě je celkem jedno, čím začít, obě to jsou pěkné technologie. Takže si to odhlasujte, jestli začít s OpenVG (asi dostupnější pro začátky) nebo GLES (to je trošku maso řekl bych).

ok, zatim je to 100% pro OpenVG :)

Ještě můžu napsat něco o skutečném lowlevel přístupu přes mailboxy (to bylo jen zmíněno v první části), ale trošku se bojím, jestli si to najde čtenáře. Byl by zájem?

Možná hardcore, ale aspoň to vysvětlí, jak se dá efektivně na RaspberryPi s HW pracovat. To mi v této sérii podle názvu dává daleko větší smysl. Teď je k RaspberryPi vázáný prakticky jen tak trošku open("/dev/fb") a zbytek jsou obecné grafické rutiny (nic proti, je to samozřejmě zajímavé, ale trochu mimo téma)...

Mozna trosku vysvetlim, proc ty clanky vlasne vznikly (tedy nejjednodussim vysvetlenim muze byt grafomanie :):

Nekolikrat jsem se setkal s tim, ze lidi pouzivaji RPi pro nejake rizeni a mereni, coz je fajn, stoji to par korun, ma to GPIO, ethernet, takze proc ne. Tito lide mnohdy potrebuji vykreslit nejaky graf prubehu merene nebo rizene veliciny/velicin (napriklad co jim vraci cidlo a co oni posilaji do PWM). Reseni, ktera byla navrhovana, byla nekdy dost hruzne ohnuta, napriklad volani gnuplotu kazdou sekundu, reloading obrazku tvoreneho GGI, dokonce i generovani obrazku + realoading v prohlizeci pres nejaky JS timeout apod.

Pritom mnohdy staci strasne malo: umet smazat obrazovku, vykreslit body (nebo krizky), usecky, maximalne nejaky ten text. A to jde pres framebuffer snad uplne nejjednoduseji, vlastne i nejrychleji, vysledna aplikace bude mit prakticky nulove zavislosti (maximalne jen libc), v pameti zabere 00nic. Tady doufam ty rutiny k necemu pomucou. Zbyva vykreslovani pisma, ale predpokladam, ze kdo si stahne unifont, tak s pomoci osmi bitovych posunu a putpixel (coz neni optimalni) vysledku dosahne snadno.

Proc vsichni cpou 24bitove framebuffery, kdyz to ty displeje proste nemaji sanci zobrazit? Vetsinou to je tak 6 bitu/kanal max, ty spodni dva bity uz jsou tam jen do poctu... Podle me 565 bohate staci a hnedka je framebuffer na 2/3 velikosti.