Haiku - OS führte uns am 6.11. in die Welt des neuen Haiku - nativen "Haiku Vector Icon Format, oder kurz HVIF... Zu allererst: dies ist keine Abwandlung des gängigen SVG - Formats. Es ist ein neues Vector Grafik Format.

Es können aber auch Imports/Exports über Icon-o-Matic für gewöhnliche SVGs erstellt werden.

Was ist aber das 'Knoff-Hoff' von HVIF?

Lt. englischem Bericht haben SVG Icons praktische Größen von 2 - 10 kB komprimiert wie in Zeta oder sogar mehr oder referenzieren auf z.B. 80 kB große PNG - Bilder, wie z.B. im kommenden Vista.

Selbst das klassische BeOS Icon - Format hat immer noch 1280bytes.

Wenn man bedenkt, welch verlangsamender Effekt in der Performance von Prozessen im System auf das Schreiben und Lesen von Dateien lastet, sind gerade bei Suchprozessen diese Kriterien nicht unerheblich.

Diesen Sachverhalt respektiert Haiku's HVIF: es begnügt sich mit 500 - 700 Bytes!

Mit dieser Größe rutscht das Icon in die sogenannte 'Small Data Region' in BeOS/Zeta/Haiku, die in der sogenannten 'Inode' (gestreamte Dateneinheit) der Datei selbst residiert.

Das heißt mit dem 'Aufspüren' einer einzigen Datei erhält der Tracker sämtliche Informationen für diese Datei (auch die Icon - Info, die ja sonst als (z.B. komprimiertes) SVG - oder PNG - Format ebenfalls irgendwo auf der Platte abgelegt ist und so mit einer weiteren Suchoperation auf der Platte gefunden/assoziiert werden müßte), alle Informationen der Datei werden sozusagen in einer einzigen Festplatten-Operation bereitsgestellt.

Dies hat also demnach dramatische positive Auswirkungen auf Tracker Queries. Suchanfragen werden so um ein Vielfaches beschleunigt.

Andere Betriebssysteme gehen mittlerweile andere Wege, um diesen physikalsichen Verzögerungen bei den Suchvorgängen entgegenzuwirken: sie bauen im Laufe des Betriebs einen auch manuell konfigurierbaren FT (Fulltext) - Index in einer Datei oder Datenbank auf, welcher auch manuell konfigurierbar ist. Idealerweise würde das eine oder andere OS dann versuchen, diese Index-DB inkl. Prozeß im RAM zu halten, wenn die RAM-Speicherreserven es zulassen.

Anders ist eine halbwegs flotte Suchanfrage bei den neuen Betriebssystemen auch kaum zu bewerkstelligen.

Der Ansatz in Haiku ist jedoch ein anderer und 'stimmt': um Live - Queries zu verbessern und eine RT-Performance zu gewährleisten, ist die Minimierung der physikalischen Lesevorgänge bei Suchanfragen auf der Platte oberstes Gebot. Denn nichts vergeudet soviel Zeit wie Bewegungen auf der Platte.

Nun zu einer weiteren Eigenschaft des HVIF:
es rendert die Vektorgrafik in einem Durchgang (Single Pass) im Gegensatz zu SVG, das in mehreren Durchgängen rendert und die Schichten übereinanderlegt. Um die Präzision und Klarheit der Icons trotzdem in einem Durchgang realisieren zu können, nutzt HVIF die in Haiku vorhandenen und erstmals bei BeOS/Zeta von Wonderbrush genutzten 'Anti - Grain Geometry' Rendering Technologie/Bibliotheken. Diese wird übrigens auch in der Desktopdarstellung in Haiku genutzt werden.

Zusammenfassend kann man sagen, das hier ein Ansatz verfolgt wird: Performance - Verbesserungen im kleinsten Detail können dramatische globale Auswirkungen in dem Sytem beherbergen.

My 2Cents:
Ich denke, das diese Entwicklung nach dem wirklich einzigartigen Feature des Locale Kits in Zeta eine auch für andere Plattformen referenzierbare Technologie der Post BeOS - Entwicklergemeinde darstellt.

In dem Bericht geht Stephan noch tiefer in die Materie auf Entwickler - Ebene und bestätigt eine entsprechende Icon Design - Dokumentation, die in Arbeit sei. Da diese Arbeit eine 'work in progress' ist, ist hier also noch kein fertiges Produkt entstanden.

Aber es zeigt die Möglichkeiten geschickter Nutzung neuer Technologien, entgegen dem Trend der Code-Verschwendung anderer Plattformen wie Windows, Linux oder OS X noch sparsamer mit Codezeilen als auch mit dem Speicheraufkommen umgehen zu können.

Einen Screenshot von dem momentanen Status der Arbeit seht ihr hier.


Weiter so, Haiku Team!