Darling progress report - červenec 2013

31.7.2013 12:00 | Přečteno: 2470× | Linux | | poslední úprava: 31.7.2013 15:59

Ačkoliv se Darling občas objeví na Phoronixu, tak Phoronixu se nedá věřit. Jeho redaktor se mnou nikdy nebyl v kontaktu, takže si jen dělá obrázek podle toho, co někde zahlédne, takže zpravodajství opravdu na prd. Co teprve weby, co to od něj opíšou (zdravíme ZDNet).

• Darling nyní umí spustit konzolové programy jako Midnight Commander, VIM nebo Bash, takže kompatibilita základních systémových API je na tom už hodně dobře.
• Refaktoruji kód dynamického zavaděče, protože používá návrh ještě původního autora a to je zoufalství. Bez refaktorování by nebylo možné asi ani pořádně podporovat unload dynamických knihoven. Jako bonus pak bude zavaděč moci fungovat podobně jako libhybris, bude tedy možné si pomocí API zavaděče načíst v nativní aplikaci nějakou knihovnu zkompilovanou pro OS X.

• Naimplementoval jsem FUSE modul darling-dmg podporující soubory DMG (ve kterých se dodává většina obyčejných aplikací/her). Soubory DMG obsahují blokově komprimovaný obraz disku (včetně tabulky oddílů), přičemž na jednom z oddílů najdete systém souborů HFS+/HFSX. darling-dmg jej zpřístupní v režimu read-only.

  Důvod? Bez tohoto programu by na Linuxu bylo nutné obraz nejprve rozbalit (dmg2img), což je u obrazu v řádu gigabajtů neefektivní, pak by se z něj vybral jeden oddíl a ten by se musel (jako root) připojit pomocí podpory hfsplus v jádře. Ta mi přitom docela běžně dělá Oops jádra následovaný kompletním deadlockem systému. Nechápu, že tam ten kepl tolerují.

• Chystá se podpora instalačních balíčků .pkg v projektu darling-installer. Jde o XAR archivy obsahující instrukce v XML, před/po instalační skripty v Bashi a payload v CPIO/GZIP.
• Při vývoji jsem zjistil, že zdrojové kódy GCC uvolněné Applem neodpovídají dodávané binárce. Čichám, čichám porušení GPL. V jejich binárce je totiž nějaký ošklivý kód navíc, který předpokládá, že malloc() vrací vynulovanou paměť - což na OS X obvykle platí, na Linuxu ne. V jimi dodávaném zdrojovém kódu je daná věc implementovaná viditelně jinak a správně.

Core Audio

Pod celkem Core Audio se skrývá skupina frameworků pro práci se zvukem na OS X. Je to opravdu rozsáhlé - je možné přehrávat zvuk, konvertovat mezi různými komprimovanými/nekomprimovanými formáty, přidávat efekty, pracovat s kontejnery a tak dále. V Darlingu pro implementaci používám knihovny ffmpeg/libav (libavcodec, libavformat, libavresample, ...) a jako jediný backend mám zatím ALSA (libasound).

Cílem zatím není reimplementovat celý konglomerát. Zatím jde jen o to rozchodit mpg123 pro OS X na Linuxu, které používá jen základní minimum těchto API. Takže až někde napíšou, že smyslem Darlingu je používat mpg123, tak budete vědět, která bije.

Problém jménem GNUstep

GNUstep, který používám pro poskytnutí frameworků Foundation, CoreFoundation a AppKit, bohužel nese všechny známky neperspektivního projektu. Díky mně se podařilo rozhýbat Toll-Free Bridging - tedy propojení Foundation a CoreFoundation - a oba tyto frameworky jsou na tom docela dobře, ale AppKit (tedy gnustep-gui) je naprostá tragédie.

Od prvních screenshotů před 10 měsíci jsem nerozchodil žádnou další GUI aplikaci, co bych mohl ukázat. Dokonce ani žádnou další GUI aplikaci, co bych si sám vytvořil. Tak blbě na tom ten projekt je.

I když jim poskytnu backtraces a další ukázky, podle kterých je jasné, v čem problém spočívá, tak ho nikdo neopraví a ani mi neporadí, jak ho opravit. Ani se na tom nedokážou pořádně shodnout. Zatímco všechny další oblasti Darlingu postupují viditelně vpřed, tady to stojí na mrtvém bodě.

Ten projekt ani nemá "man power" na to vyvíjet chybějící součásti, protože jako samostatný toolkit všechno musejí dělat od píky. Mají sice tři backendy (xlib, art, cairo), ale ani jeden z nich nefunguje pořádně. Sužují je problémy typu "při přejetí myší přes textedit už je kurzor myši navždy I-beam". Pod jedním to tiskne, pod druhým to blbne, prostě bordel. A ještě to vypadá fakt hnusně.

Z dlouhodobého hlediska proto vidím naději spíše ve vlastní implementaci tříd Cocoa nad existujícím GUI frameworkem, kterým by bylo Qt. Při procházení struktury Cocoa nevidím žádné zásadní problémy, které by tomu měly zabránit. Vzhledem k tomu, že bych využíval ostatní knihovny od GNUstepu, tak by mohly jednoduché aplikace fungovat docela rychle.

Někteří tento nápad sice označili jako šílený, ale já to tak nevidím:

• gnustep-gui je při použití s aplikacemi pro OS X tak špatné, že i základní rozpracované cosi nad Qt bude zákonitě fungovat lépe.
• Většina práce s implementací widgetů se nemusí dělat. gnustep-gui doteď nemá ani NSDatePicker (widget pro výběr data).
• Mohu to dělat vysokoúrovňově v (Objective)-C++. Navíc se můžu vykašlat na podporu zastaralých kompilátorů, jakým je z hlediska ObjC právě GCC. Příspěvky do GNUstepu jsou podmiňovány podporou GCC, takže si člověk nemůže usnadnit práci ani o píď a musí se se vším psát jako blbec.

Cílová aplikace

Cílovou aplikací, kterou někde vypíchnu, aby se zpravodajci měli čeho chytat, je Angry Birds. Z marketingového hlediska je to velmi dobrý tah (populární věc), nemá to nativní verzi pro Linux (takže se nikdo nemusí jako blbec ptát, proč rozcházím Midnight Commander) a nepoužívá to až tak velký rozsah API pro OS X. Angry Birds používají OpenGL, OpenAL, IOKit (pro nalezení vstupních zařízení), AppKit (pro vytvoření okna), CGL (pro nastavení OpenGL - obdoba GLX) a Core Video (pro spuštění vykreslovací smyčky).

       

Komentáře

[pavlix]

Nechápu, že tam ten kepl tolerují.

V jádře jsou daleko horší věci :D.

[pavlix]

Při vývoji jsem zjistil, že zdrojové kódy GCC uvolněné Applem neodpovídají dodávané binárce. Čichám, čichám porušení GPL.

Čas spojit se s GPL violations?

[pavlix]

Navíc se můžu vykašlat na podporu zastaralých kompilátorů, jakým je z hlediska ObjC právě GCC. Příspěvky do GNUstepu jsou podmiňovány podporou GCC, takže si člověk nemůže usnadnit práci ani o píď a musí se se vším psát jako blbec.

Chápu to dobře, že pro dnešní aplikace má smysl ObjC kompilovat jen v LLVM, pokud se nechceš dostat do zmíněných problémů? Vyvíjí se GCC v tomto směru? Dá se bez větších problémů kombinovat výstup GCC a LLVM (třeba při použití různých jazyků)?

[Luboš Doležel (Doli)]

Ano. Na Clangu dělají přímo v Apple, kdežto ObjC v GCC se dlouho nevyvíjí. Některé chybějící věci jsou docela kritické.

Výstup (*.o) GCC a LLVM se kombinovat dá. Dokonce existuje projekt LLVM-GCC.

[dumblob]

Klobouk dolu! Co se Cocoa API nad Qt tyce, tak to proveditelne je (tedy silene ne). Jenom to zabere ukrutne moc casu

[mirec]

Implementácia cocoa v Qt ... znie tak trochu šialene. Len tak pre zaujímavosť má to byť stavané na Qt 4, alebo Qt 5? Momentálne trochu rýpem do Qt 5 (hlavne kvôli embedded kde behá na mojich hračkách celkom slušne, mimochodom tu grafika beží na 180MHz), ale aj napriek tomu nemám moc dôveru v Qt. Stabilita je miestami oproti Qt 4 hrozná, okná o plynulom resize môžu len snívať ... Celkovo vykresľovanie na Qt 4 bolo také ľahšie. Úplná šialenosť bude až bude Qt aplikácia pre Mac bežať pod linuxom emulovane vykresľovaná cez Qt :D

[Luboš Doležel (Doli)]

Qt 5 jsem ještě vůbec neřešil, v Gentoo je stále zamaskované. Qt ale považuju za to nejlepší, co na Linuxu je.

[mirec]

Keby len zamaskované, ale ono je ešte len v overlayi

Qt 3 som považoval za to najepšie na linuxe, krásny výkon cez X11 forwarding kde som nerozpoznal, či aplikácia beží lokálne, alebo vzdialene. Potom bum Qt 4 s príšerným výkonom, ale postupne som si zvykol, prišli alien widgety a výkonnostné optimalizácie a dalo sa to používať. Na Qt 5 sa zatiaľ optimalizácie moc neriešili. Celkovo sa teraz Qt orientuje skôr na OpenGL a myslím, že na raster začne pomaly sadať prach. OpenGL má celkom slušný výkon pri "moderných" UI v QML, ale klasické UI skladané z čiar, gradientov ... sú pomalé kvôli častým zmenám kontextu. Obávam sa, že práve kvôli tomu môže mať vykresľovanie na Qt 5 dosť veľké problémy. Alebo možno mám zle zladený hardvér a problémy s výkonom mám len ja ... (rád by som si prečítal názor niekoho kto robí s Qt 5, ja som pomerne malá vzorka ).

[kralyk z abclinuxu]

Mně přijde výkon v Qt5 ok, ale X11 forwarding nepoužívám (imho marginální use case). Akorát mi blbnou menu (kontextová a aplikační), trvá dlouho, než se zobrazí. Vypadá to jako nějakej problém s animací nebo tak něco...

Uvidím ještě jak to půjde, až přejde na Qt5 KDE.

[mirec]

Ja fungujem bez kompozitného desktopu a porovnávam hlavne zmenou veľkosti okna, ktorá znamená kompletné prekreslenie okna (inak widgety môžu byť double bufferované, resizom sa zaistí, že všetky sa musia prekresliť). Ak otvorím napr. qt creator a jeho nastavenia, tam mením veľkosť okna tak na pravej časti okna sa najskôr vykresľuje čierna plocha, až potom okno. Zrejme to bude problém spojený s xcb.

[kralyk z abclinuxu]

U mně nic takovýho není (ať už s akcelerovaným WM nebo bez), máš aktuální verzi?

[mirec]

Áno, aktuálnu (arch linux). Ak zajtra nezabudnem do práce doniesť fotoaparát tak natočím.

[mirec]

Takže tu je video. To prvé je Qt 4, druhé Qt 5. Pri Qt 5 vidno čierny pravý okraj okna.

[mirec]

Ešte jedno srandovné videiko, tentoraz preferovaný spôsob vykresľovania GUI v Qt 5 - qtquickcontrols. Tu je video.

[kralyk z abclinuxu]

Zajímavý. Jestli za to nemůže WM, tak to asi opravdu bude nějakej problém v Qt5...

Jinak já odvolávám ten problém s app/context menu, teď jsem zjistil, že to samý se děje občas v GTK, takže problém bude někde jinde...

[mirec]

No wm ... ako sa to tak vezme. V dnešnej dobe už môže byť za prolbém považované to, že nie je kompozitný. V kompozitných správcoch ako som pozeral sa resize moc nerieši, namiesto toho sa resizuje len textúra a expose sa pošle až po dokončení resizu.

[Ovocníček]

Bulánci pro Mac počítám neexistujou, co? :D

[zxtlpn]

Not enough facepalms in the world.