2 Punkte von GN⁺ 2024-04-03 | 1 Kommentare | Auf WhatsApp teilen

Erfahrungen bei Adobe und die Entstehung von Renderlet

  • Arbeit an der Infrastruktur großer Anwendungen wie Photoshop und Acrobat bei Adobe.
  • Es war ein großes Kopfzerbrechen, eine leistungsfähige Codebasis auf Desktop, Web, Mobile und in der Cloud zum Laufen zu bringen.
  • Um Lightroom und Photoshop im Web lauffähig zu machen, war ein komplexer Weg über JavaScript, Googles PNaCl, asm.js und schließlich WebAssembly nötig.
  • Dafür mussten die GPU-Architektur neu gedacht, Single-Thread-Builds zum Laufen gebracht und die UI rund um Web Components neu aufgebaut werden.
  • Der Web-Build funktioniert heute gut, aber bis dorthin war es ein langer Weg von zehn Jahren.

Das Potenzial von WebAssembly

  • Der Grafik-Stack ist der Teil, der bei der Portabilität den größten Engpass verursacht.
  • Eines Tages wurde klar, dass WebAssembly (Wasm) für dieses Problem eine Lösung bieten könnte.
  • Wasm kann überall ausgeführt, in alles eingebettet werden und bietet genug Leistung für Echtzeitgrafik.
  • Daraufhin wurde der Job gekündigt und das Abenteuer begonnen, von Grund auf ein auf WASM basierendes, portables und einbettbares Grafik-Framework zu bauen.
  • Es soll Anwendungsentwicklern ermöglichen, die gewünschte Grafik einfach zu erstellen, und dabei sowohl ein hohes Abstraktionsniveau als auch Low-Level-Funktionen bieten, um alles auszuschöpfen, was für Hochleistungsanwendungen einschließlich GPU nötig ist.

Einführung in Renderlet

  • Der Name Renderlet wurde gewählt, um den Aspekt der Einbettbarkeit zu betonen.
  • Eigene Grafikmodule können erstellt und verbunden werden, sodass sie mit allem und in allem einfach interoperabel sind.
  • Ähnlich wie Unity es Entwicklern erleichtert hat, plattformübergreifende Spiele zu erstellen, ist die Idee, dasselbe für alle visuellen Anwendungen zu tun.

Entwicklungsprozess und Bitte um Feedback

  • Teilnahme an YC als Solo-Gründer, wobei der Großteil der Zeit in den vergangenen sechs Monaten auf den Aufbau dieses Projekts verwendet wurde.
  • Für eine Open-Alpha-Veröffentlichung ist es noch nicht ganz bereit, aber bald, und dazu soll geschrieben, etwas gezeigt und Feedback eingeholt werden.
  • Das ist etwas, wovon man als Anwendungsentwickler immer geträumt hat, und es besteht großes Interesse daran, was andere darüber denken.

Kombination von Rive und Renderlet

  • Als Rive seine 2D-Vektor-Engine als Open Source veröffentlicht hat und damit Aufmerksamkeit bekam, war das besonders interessant.
  • Der Renderer von Rive ist mit einer SVG-ähnlichen High-Level-2D-API aufgebaut, während der Wander-Renderer von Renderlet eine Low-Level-3D-API über der GPU bereitstellt.
  • Renderlet kann mit seinem GPU-Backend die Bibliothek Rive Renderer ausführen, wodurch jede 3D-App ein 2D-Vektor-Backend bekommen kann.
  • Eine tatsächliche Implementierung in Aktion ist auf Vimeo zu sehen, und auf GitHub kann man tief in die technischen Details eintauchen.

Meinung von GN⁺

  • Renderlet präsentiert einen innovativen Ansatz, um die bestehenden komplexen Portierungsprobleme von Grafik-Anwendungen zu lösen. Das könnte für Entwickler ein leistungsstarkes Werkzeug werden, um auf unterschiedlichen Plattformen eine konsistente Benutzererfahrung bereitzustellen.
  • Der Entwickler von Renderlet versteht auf Basis seiner Erfahrungen bei Adobe die realen Marktanforderungen und technischen Grenzen sehr gut, was die Erfolgschancen des Projekts erhöht.
  • Allerdings befindet sich Renderlet noch in einer frühen Phase und ist noch nicht als Open Alpha veröffentlicht, daher sind Leistung und Stabilität in realen Umgebungen noch nicht validiert.
  • Damit sich diese Technologie erfolgreich durchsetzen kann, braucht es breite Unterstützung aus der Community und eine aktive Beteiligung von Entwicklern. Als Open-Source-Projekt werden Beiträge und Feedback der Entwickler das Wachstum des Projekts stark beeinflussen.
  • Andere Projekte oder Frameworks mit ähnlichen Funktionen sind Unity, Unreal Engine und Godot, doch Renderlet verfolgt einen differenzierten Ansatz mit stärkerem Fokus auf Wasm-basierte Schlankheit und Portabilität.

1 Kommentare

 
GN⁺ 2024-04-03
Hacker-News-Kommentare
  • Es ist besser, die PAL-Phase zu überspringen und direkt zu SetupRuntime zu gehen. Nicht-Grafikentwickler kennen solche Details oft nicht, und es ist nicht wünschenswert, der API unnötige zusätzliche Schritte hinzuzufügen. Da PAL anderswo nicht verwendet wird, wäre es besser, WebGPU zu nutzen. (IPal sollte ein Mitglied von IRuntime sein und ist bereit, im WebGPU-Kontext entfernt zu werden).

    • Empfehlung zur Nutzung von WebGPU: PAL-Phase auslassen, direkt mit SetupRuntime beginnen, Notwendigkeit der API-Vereinfachung, Integration von IPal in IRuntime und geplante Entfernung.
  • Dieses Projekt könnte eine großartige Widget-Toolkit- und erstaunliche Canvas-Basis für die Entwicklung plattformübergreifender GUIs werden. Mit dem C/C++-Backend und dem WASM-Ziel ließe sich in nahezu jeder Sprache ein FFI aufbauen.

    • Potenzial für plattformübergreifende GUI-Entwicklung: Aufbau von FFI in verschiedenen Sprachen möglich, Vorteile von C/C++-Backend und WASM-Ziel.
  • Ich frage mich, was für Text- und Font-Unterstützung geplant ist. Manche Grafik-Engines unterstützen Text nicht in allen gewünschten Formen. Die Frage ist, ob OTF- oder WOFF2-Dateien geladen und beliebige Zeichenketten angezeigt werden können.

    • Frage zu Text- und Font-Unterstützung: Unterstützung verschiedener Arten der Textdarstellung, Laden von OTF-/WOFF2-Dateien und Anzeige von Zeichenketten.
  • Großes Interesse an dem Projekt. Es gibt einige Fragen zu Runtime, Event-Loop, FFI und Besitzverhältnissen von Window-Pointern. Außerdem besteht Interesse an Audio-Plugins und VSTs, wobei es Einschränkungen beim Event-Loop und Window-Management gibt. JUCE ist de facto die Lösung, aber veraltet und umständlich.

    • Interesse an Audio-Plugins und VSTs: Fragen zu Runtime, Event-Loop, FFI und Window-Management, Potenzial als Alternative zu JUCE.
  • Dieses Projekt ist wirklich großartig und genau das, wovon ich in den letzten Jahren geträumt habe. WASM hat großes Potenzial als portable Einheit für Grafik-, Audio- und Multimedia-Berechnungen.

    • Hervorhebung des Potenzials von WASM: Möglichkeiten von WASM als portable Einheit für Grafik-, Audio- und Multimedia-Berechnungen.
  • Ich arbeite daran, WASM in der Godot Engine zum Laufen zu bringen. Mich würde interessieren, wie die Probleme mit der Zugänglichkeit von Shared Array Buffers in Safari und dem für Online-Spiele wichtigen Zugang zu Werbenetzwerken überwunden wurden. Außerdem wird das Problem Single-Thread vs. regulärer Build angesprochen.

    • Arbeit an Godot Engine und WASM: Probleme mit Shared Array Buffers in Safari, Zugang zu Werbenetzwerken, Single-Thread- vs.-regulärer-Build-Thema.
  • Ich freue mich, mehr Projekte im Bereich 3D-Grafik/WASM zu sehen. Es wird nach Tipps gefragt, um in YC aufgenommen zu werden. Seit Jahren wird an einem Port von Unreal Engine 5 auf WebGPU und WebAssembly gearbeitet. Es gibt einen Multithread-Renderer und ein Asset-Streaming-System, sodass Nutzer nicht das gesamte Spiel bzw. die gesamte App im Voraus herunterladen müssen. Außerdem muss nicht die komplette Anwendung auf einmal in den Speicher geladen werden. Es wurde auch eine vollständige Hosting-Plattform samt Backend aufgebaut, über die Entwickler ihre Projekte online bereitstellen können.

    • Portierung von Unreal Engine 5 auf WebGPU und WebAssembly: Multithread-Renderer, Asset-Streaming-System, kein vollständiger Download von Spiel/App nötig, Aufbau von Hosting-Plattform und Backend.
  • Der Vortrag bei wasm I/O war beeindruckend, und es freut mich zu sehen, dass diese Arbeit Aufmerksamkeit bekommt.

    • Positive Reaktion auf den Vortrag bei wasm I/O: Eindrucksvoller Vortrag und wachsende Aufmerksamkeit für die Arbeit.
  • Es wird gefragt, ob der Artikel von Ian Hickson, einem der Hauptentwickler von Flutter, gelesen wurde. Darin wird das Konzept erläutert, mit WASM ein vollständig plattformübergreifendes UI-Framework zu haben, und genau dieses Konzept nutzt Flutter.

    • WASM-Nutzung im Zusammenhang mit Flutter: Konzept eines plattformübergreifenden UI-Frameworks, Verbindung zu Flutter.
  • Für den CAD-Kernel wird manifold nachdrücklich empfohlen, das sich in Apps integrieren lässt.

    • Empfehlung für einen CAD-Kernel: Empfehlung von manifold zur Integration in Apps.