L’expérience chez Adobe et la naissance de Renderlet
- Il a travaillé sur l’infrastructure de grandes applications comme Photoshop et Acrobat chez Adobe.
- Faire fonctionner une base de code puissante sur desktop, web, mobile et cloud était un casse-tête majeur.
- Pour faire tourner Lightroom et Photoshop sur le web, il a fallu passer par un parcours complexe impliquant JavaScript, PNaCl de Google, asm.js, puis finalement WebAssembly.
- Il a fallu repenser l’architecture GPU, faire fonctionner des builds monothread et réorganiser l’UI autour des composants web.
- Le build web fonctionne bien aujourd’hui, mais il a fallu un long parcours de 10 ans pour en arriver là.
Le potentiel de WebAssembly
- La pile graphique est l’élément qui crée le plus gros goulot d’étranglement en matière de portabilité.
- Un jour, il a réalisé que WebAssembly (Wasm) offrait une solution à ce problème.
- Wasm peut s’exécuter partout, s’intégrer à n’importe quoi et offre des performances suffisantes pour les graphismes en temps réel.
- Il a donc quitté son emploi et s’est lancé dans l’aventure de créer, à partir de zéro, un framework graphique portable et intégrable basé sur WASM.
- L’objectif est d’offrir aux développeurs d’applications un cadre de haut niveau pour créer facilement les graphismes souhaités, tout en fournissant des capacités bas niveau exploitant au maximum tout ce qui est nécessaire aux applications hautes performances, y compris le GPU.
Présentation de Renderlet
- Le nom Renderlet a été choisi pour souligner son aspect intégrable.
- Il permet de créer et connecter ses propres modules graphiques, et d’interopérer facilement avec n’importe quoi, dans n’importe quel environnement.
- De la même manière que Unity a permis aux développeurs de créer facilement des jeux cross-platform, l’idée est de faire la même chose pour toutes les applications visuelles.
Processus de développement et demande de retours
- Il a rejoint YC en tant que fondateur solo, mais a consacré l’essentiel de son temps, ces six derniers mois, à construire ce projet.
- L’open alpha n’est pas encore prête, mais elle le sera bientôt, et il souhaite en parler, la montrer et recueillir des retours.
- C’est quelque chose dont il rêvait en tant que développeur d’applications, et il veut savoir ce qu’en pensent les autres.
Combiner Rive et Renderlet
- Il a été intrigué lorsque Rive a open sourcé son moteur vectoriel 2D et a fait parler de lui.
- Le renderer de Rive est construit sur une API 2D de haut niveau proche de SVG, tandis que le renderer Wander de Renderlet expose une API 3D de bas niveau au-dessus du GPU.
- Renderlet peut exécuter la bibliothèque Rive Renderer en utilisant son backend GPU, ce qui permet à toutes les applications 3D de disposer d’un backend vectoriel 2D.
- Il est possible de le voir réellement implémenté et en fonctionnement sur Vimeo, et d’explorer les détails techniques en profondeur sur GitHub.
L’avis de GN⁺
- Renderlet propose une approche innovante pour résoudre les problèmes complexes de portage des applications graphiques existantes. Cela pourrait devenir un outil puissant permettant aux développeurs d’offrir une expérience utilisateur cohérente sur diverses plateformes.
- Le développeur de Renderlet comprend bien les besoins réels du marché et les limites techniques grâce à son expérience chez Adobe, ce qui renforce les chances de succès du projet.
- Cependant, Renderlet en est encore à un stade précoce et l’open alpha n’étant pas encore disponible, ses performances et sa stabilité en conditions réelles restent à valider.
- Pour que cette technologie soit adoptée avec succès, un large soutien de la communauté et une participation active des développeurs seront nécessaires. En tant que projet open source, les contributions et retours des développeurs auront un impact important sur sa croissance.
- D’autres projets ou frameworks offrant des fonctionnalités similaires incluent Unity, Unreal Engine et Godot, mais Renderlet adopte une approche différenciée davantage axée sur la légèreté et la portabilité basées sur Wasm.
1 commentaires
Avis Hacker News
Il vaudrait mieux sauter l’étape PAL et passer directement à SetupRuntime. Les développeurs non spécialisés en graphisme ne connaissent pas bien ce genre de détails, et il n’est pas souhaitable d’ajouter une étape supplémentaire inutile à l’API. PAL n’est utilisé nulle part ailleurs, donc il vaudrait mieux utiliser WebGPU. (
IPaldevrait être un membre deIRuntimeet est prêt à être supprimé dans le contexte WebGPU).IPaldansIRuntimeet suppression prévue.Ce projet pourrait devenir une superbe boîte à widgets pour créer des interfaces graphiques multiplateformes, ainsi qu’un canevas remarquable pour des modèles d’interaction. Le backend C/C++ et la cible WASM permettent de construire une FFI dans pratiquement n’importe quel langage.
Je me demande quels sont les plans pour la prise en charge du texte et des polices. Certains moteurs graphiques ne gèrent pas le texte de toutes les façons souhaitées. Question sur la possibilité de charger des fichiers OTF ou WOFF2 et d’afficher des chaînes arbitraires.
Grand intérêt pour ce projet. Il y a quelques questions sur le runtime, la boucle d’événements, la FFI et la propriété des pointeurs de fenêtre. Intérêt aussi pour les plugins audio et les VST, avec certaines contraintes sur la boucle d’événements et la gestion des fenêtres. JUCE est la solution de facto, mais c’est ancien et peu pratique.
Ce projet est vraiment formidable, c’est exactement ce dont je rêve depuis plusieurs années. WASM a un énorme potentiel comme unité portable pour les calculs graphiques, audio et multimédia.
Je travaille actuellement à faire fonctionner WASM dans Godot Engine. Je me demande comment vous avez surmonté les problèmes d’accessibilité des SharedArrayBuffer dans Safari ainsi que les problèmes d’accès aux réseaux publicitaires, qui sont importants pour les jeux en ligne. Il est aussi souligné qu’il y a un problème entre les builds mono-thread et les builds normaux.
Ravi de voir davantage de projets dans le domaine de la 3D graphique/WASM. Question sur d’éventuels conseils pour entrer chez YC. Travail en cours depuis des années sur le portage d’Unreal Engine 5 vers WebGPU et WebAssembly. Il existe un moteur de rendu multithread et un système de streaming d’assets, de sorte que les utilisateurs n’ont pas besoin de télécharger tout le jeu ou toute l’application à l’avance. Il n’est pas non plus nécessaire de charger toute l’application en mémoire d’un seul coup. Une plateforme d’hébergement complète et un backend ont également été construits pour permettre aux développeurs de déployer leurs projets en ligne.
La présentation à wasm I/O était impressionnante, et je suis heureux de voir que ce travail attire l’attention.
Question sur la lecture d’un article de Ian Hickson, développeur principal de Flutter. Il y explique le concept d’un framework d’interface utilisateur totalement multiplateforme à l’aide de WASM, ce qui correspond au concept utilisé par Flutter.
Recommandation appuyée de
manifoldcomme noyau CAD pouvant être intégré à l’application.manifoldpour une intégration dans l’application.