Jde udelat jednoduse plynuly scrolling tak, ze by se nastavila vetsi plocha virtualniho framebufferu vuci zobrazenemu. Potom by se to nejak posunovalo jen zapisem pres mailboxy podobne, jako tomu bylo na starem dobrem Atarku (v podstate jeden dulezity efekt prakticky zadarmo zapisem dvou tri bajtu).
To je na jednu stranu pravda, na druhou stranu to treba RPi neustiha (a obecne taky neni dobry prenaset cely buffer porad tam a zpet). Zrovna v tomto pripade by se dal pouzit GLES, ale ten neni 100% prenositelny, to je fakt (zase, na RPi to je to nejlepsi, co to zarizenicko umi :), protoze samotny CPU je relativne slaby.
Teoreticky by to slo udelat, ale ne uplne jednoduse a navic je (asi porad jeste) problem s rekonfiguraci framebufferu pri behu RPi. Takze fallback uz navrhl predrecnik tom__, pres operace v back bufferu (100% prenositelne) nebo GLES popr. texturovani podporovane nejakou knihovnou nad tim (ted z hlavy nereknu, jestli SDL uz umi GLES na RPi, musim dohledat).
Mna by celkom zaujimalo ako sa robi effekt ktory pozname na Smartfonoch
ze dokazeme tu obrazovku posunut napriklad doprava/dolava.
To si tiez vyzaduje pomerne vela grafickej pamate a predrenderovany
screen ktory nebol aktivny?
Osobne by mi stacilo nieco ako ma Android
par ikon touch a nejaky ten slide kvoli viac ikonkam pre spustenie akcii/podprogramov.
Inak namet pre dalsie pokracovanie xvfb alebo nejaka light
alternativa k widgetom. pripadne ako na GUI like photon (male a rychle) :)
No muzes pres GLES generovat GUI widgety a dalsi nesmysly primo do texturovaci pameti a potom jedinou operaci je vykreslit (otexturovany obdelnik), aplikovat tam ruzne filtry typu prusvitnost apod. Ma to tu vyhodu, ze se neprenasi data mezi CPU a GPU, nevyhodou je o dost slozitejsi reseni a take operace typu putpixel apod. jsou trosku pres ruku.
Mam takovy trosku spatny pocit, ze dneska bezne GUI umira a vsechno se dela v CSS+JavaScriptu. Jak na Gnome, tak i na woknech. Potom to dopadne tak, ze textovy editor si vezme 50 MB RAM jen se po ni zaprasi hned po startu. Takze za me: absolutni podpora pro lehkotonazni GUItka.
Kdysi jsem psal aplikaci s grafikou na framebuffer, ale teď už bych tam určitě do systému zakompiloval podporu SDL. Ono už laděni na PC vyžaduje povolit v jádře framebuffer a nespouštět Xka. Měl jsem k dispozici CPU SH4 a 64MB, kdy jsem 50MB potřeboval pro aplikaci zbytek byl pro kernel a initrd. Naštěstí kreslení kreslení základních grafických prvků (čar, kruhů, tlačítek, textových polí atd.) již měl hotovou z jiné jednočipové aplikace.
Ale když jsem pak zkoušel SDL a pro toto zařízení zkompilovat hru "prdoom", tak jsem zjistil, že framebuffer pomocí ioctl umí nastavovat počátek zobrazení. SDL toto pak využívá pro doublebuffering. Tak jsem doplnil driver o tuto funkcí (samozřejmě na úkor RAM) a rozhodně hra byla rychlejší. Určitě by nebyl problém i plynulého scrollingu. I ffplay pod SDL nebylo video trhaný. Kopírování na SH4 bylo žroutem výkonu.
Dnešní grafiky umožňují zobrazování vícevrstev a v systému se může objevit několik /dev/fb. Tak není problém, třeba do videa, jinou aplikací jednoduše doplnít nějaké OSD informace. S kapacitou současných embedded zařízení už není problém doplnit grafickou nadstavbu a aplikaci mít v ní.
Ja jsem zacal mit s SDL trosku problem s prechodem na verzi 2.0. Verze 1.x byla skvela, bezela klidne i nad cistym framebufferem nebo directdraw, ale v 2.0 kompletne zmenili API. Coz o to, problem je, ze v systemech jeste 2.0 defaultne neni, podpora RPi je mizerna atd.
Podobne zmrsili i Allegro, kterou jsem mel jeste radeji nez SDL.
Zajimavy je, ze na RPi klidne muzes ladit framebufferovy aplikace primo z X, protoze se tam (aspon v Rasbiannu) pouziva ovladac pracujici prave pres framebuffer, takze mu tam muzes nacpat vlastni data. Potom staci prepnout plochu nebo maximalizovat okno a vynuti se prekresleni puvodniho GUIcka. Ostatne ty demonstracni priklady jsem takto psal, protoze me nebavi zpusob vykresleni kurzoru v RPi terminalu (jsem 'odkojeny' blokovym neblikajicim kurzorem, ne nejakou blikajici carkou :)
Zrovna nedavno se mi dostal do ruky jeden platebni terminal postaveny na linuxu (SoC Maxim, puvodne Zilog Zatara) s barevnym display (320x240x16b).
Bohuzel, tento display je pripojeny pres SPI a implementace framebufferu je plne software, tj. framebuffer je pouze a jenom v systemove pameti a pouze pri kazdem ioclt(FB_REFRESH) se pres SPI prenese celych 150kb na display.
Celkove to vychazi maximalne tak na 15fps.
Navic, tento framebuffer podporuje pouze tento jeden specificky mod 320x240x16b (coz je ale celkem logicke :-), kazdy pokus o nastaveni jakehokoliv jineho konci s chybou.
Sranda je, ze terminal nema ani klavesnici (je urcen pouze jako contactless a pro male castky, tedy vzdy bez overovani uzivatele) a tudiz ani zadnou systemovou konzolu, pouze seriovy port (USB CDC) a ethernet.
Puvodni pokusy o port Chocolate Doomu dopadly spatne: SDL ani DirectFB nejdou pouzit, jelikoz:
1) predpokladaji fyzickou konzoli a ctou z ni
2) snazi se menit rozliseni a hloubku displayi ...
Takze nakonec byl resenim specialni SDL home-made driver pro tento terminal, kde
a) z stdin (seriova konzole, telnet) ctu klavesy a simuluju stisky a pousteni (bud timeout nebo stik jine klavesy)
b) simuluju i vetsi/mensi rozliseni a orezavam/centruju do 320x240 (vracim vzdy SDL_FULLSCREEN | SDL_NOFRAME)
c) simuluju i jinou bitovou hloubku (ale vracim vzdy SDL_HWPALETTE) a sam prepocitvam pixely do pozadovaneho 565 formatu
Kupodivu, vysledny produkt je i celkem hratelny :-)
No podle indicii v kodu 'SDK' by to mohl byt ili9341 (https://www.adafruit.com/datasheets/ILI9341.pdf).
Bohuzel mam to zarizeni pouze 'zapujcene' a nerad bych provadel 'vivisekci' ....
Kazdopadne v teto implementaci je zrejmne 'natvrdo' pripojeny pres SPI a zadny buffering na strane display se neprovadi, protoze je krasne videt (kdyz clovek vi, co ma cekat) prekreslovani/tearing :-)
Vzhledem k funkci tomuto zarizeni je ten displayi az az. Zvlaste kdyz je clovek odkojeny 8-bity (u mne CBM +4, ale to si mozna pamatujes z koleji :-) - 320x200 mono nebo 160x200 4 barvy (z toho 2 pro cely screen stejne a dve menitelne per 4x8 pixel block).
Navic, ja jsem asi hardcore, a muj nazor programatora/implentatora se zde rozchazi s 'marketingem' a 'lobby' vyrobcu terminalu :-(
Podle mne ma terminal slouzit pouze a jenom k zobrazeni+potvrzeni castky a zadani PINu. Ostatni veci - barevne reklamy, .... at si resi na nejakem tabletu vedle, nebot:
a) terminal ma PCI, EMV, (a milion dalsich) certifikaci -> je to drahe a specialovane zarizeni s relativne malo pameti (16MB standard, 64-128MB luxus)
b) malokdy je to posix-like system, vetsinou nejaky specialni 'inhouse rtos like' -> prelozit na tom nejakou 'standardni knihovnu' skoro nemozne (hlavne pokud pouziva I/O funkce), clovek je rad kdyz najde neco podobneho sprintf()
c) aplikace primarne akceptuji bankovni karty, takze kazdapidizmena -> dukladne testovani vsecho
d) aplikace musi byt podepsane, takze kazda pidizmena -> procedura podpisu
e) reloaduji se pres posmanagement v bance, takze kazda pidizmena -> procesne pres banku
Vedle toho kdyz si predstavim tablet:
1) napr. 'znacka' Sencor za 2KKc
2) je tam android a 'matlaci' screen
3) aplikace na to 'sflaka' jakykoliv student bokem na kolejich
4) 'samo' sa to updatuje pres store
Ale na druhou stranu mne to zase zivi, tak co si stezuju :-)
jj CBM a další mašinky, grafika na pár kilobajtů a šlo to. Mě se na RPi (ale i na dalších podobných bobulkových a ovocných jednodeskových mikropočítačích) líbí právě ten nízkoúrovňový přístup, který na jiných strojích moc nemá smysl. Tady ale ano: máš GPIO, framebuffer, nějaké to HDI a pod tím realtime systém nebo klasický kernel (podle preferencí každého soudruha :-).
Internet Info Root.cz (www.root.cz)
Informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2021 Internet Info, s.r.o. Všechna práva vyhrazena.