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 :)