2P by neo 8달전 | favorite | 댓글 1개

Adobe에서의 경험과 Renderlet의 탄생

  • Adobe에서 Photoshop과 Acrobat과 같은 대형 애플리케이션의 인프라 작업을 했음.
  • 데스크톱, 웹, 모바일, 클라우드에서 강력한 코드베이스를 작동시키는 것이 큰 골칫거리였음.
  • Lightroom과 Photoshop을 웹에서 작동시키기 위해 JavaScript, Google의 PNaCl, asm.js, 그리고 마침내 WebAssembly를 거치는 복잡한 과정을 거쳤음.
  • GPU 아키텍처를 재고하고, 단일 스레드 빌드를 작동시키며, 웹 컴포넌트를 중심으로 UI를 재구성해야 했음.
  • 웹 빌드는 현재 잘 작동하지만, 여기에 도달하기까지 10년이라는 긴 여정이었음.

WebAssembly의 가능성

  • 그래픽 스택은 이식성에서 가장 큰 병목 현상을 일으키는 부분임.
  • 어느 날 WebAssembly(Wasm)가 이 문제의 해결책을 제공한다는 것을 깨달음.
  • Wasm은 어디서나 실행 가능하고, 어떤 것에도 삽입 가능하며, 실시간 그래픽에 충분한 성능을 제공함.
  • 이에 직장을 그만두고 처음부터 WASM 기반의 이식 가능하고 삽입 가능한 그래픽 프레임워크를 만드는 모험을 시작함.
  • 애플리케이션 개발자가 쉽게 원하는 그래픽을 만들 수 있도록 고수준이면서도 GPU를 포함한 고성능 애플리케이션에 필요한 모든 것을 최대한 활용할 수 있는 저수준의 기능을 제공함.

Renderlet 소개

  • Renderlet은 삽입 가능한 측면을 강조하기 위해 이름 지어짐.
  • 자체적인 그래픽 모듈을 만들어 연결하고, 어떤 것에나, 어떤 것 안에서나 쉽게 상호 운용할 수 있음.
  • Unity가 개발자들이 크로스 플랫폼 게임을 쉽게 만들 수 있게 한 것처럼, 모든 시각적 애플리케이션에 대해 같은 일을 하려는 아이디어임.

개발 과정과 피드백 요청

  • YC에 솔로 창업자로 참여했으나, 대부분의 시간을 지난 6개월 동안 이 프로젝트를 구축하는 데 집중함.
  • 아직 오픈 알파 릴리스 준비는 되지 않았지만, 곧 준비될 것이며, 이에 대해 글을 쓰고, 보여주며, 피드백을 받고 싶어함.
  • 이것은 애플리케이션 개발자로서 꿈꿔왔던 것이며, 다른 사람들의 생각을 알고 싶어함.

Rive와 Renderlet의 결합

  • Rive가 2D 벡터 엔진을 오픈소스로 공개하고 화제가 되었을 때 흥미를 느낌.
  • Rive의 렌더러는 SVG와 유사한 고수준 2D API로 구축되어 있으며, Renderlet의 Wander 렌더러는 GPU 위에 저수준 3D API를 노출함.
  • Renderlet이 GPU 백엔드를 사용하여 Rive Renderer 라이브러리를 실행할 수 있으며, 이를 통해 모든 3D 앱이 2D 벡터 백엔드를 가질 수 있음.
  • 실제로 구현하여 작동하는 것을 Vimeo에서 볼 수 있으며, GitHub에서 기술적인 내용을 깊이 파고들 수 있음.

GN⁺의 의견

  • Renderlet은 기존의 복잡한 그래픽스 애플리케이션 이식 문제를 해결하려는 혁신적인 접근을 제시함. 이는 개발자들에게 다양한 플랫폼에서 일관된 사용자 경험을 제공할 수 있는 강력한 도구가 될 수 있음.
  • Renderlet의 개발자는 Adobe에서의 경험을 바탕으로 실제 시장의 필요와 기술적 한계를 잘 이해하고 있으며, 이는 프로젝트의 성공 가능성을 높임.
  • 그러나 Renderlet이 아직 초기 단계에 있고, 오픈 알파 릴리스가 되지 않았기 때문에, 실제 환경에서의 성능과 안정성은 아직 검증되지 않음.
  • 이 기술이 성공적으로 도입되기 위해서는 광범위한 커뮤니티 지원과 개발자들의 적극적인 참여가 필요함. 오픈소스 프로젝트로서 개발자들의 기여와 피드백이 프로젝트의 성장에 큰 영향을 미칠 것임.
  • Renderlet과 유사한 기능을 제공하는 다른 프로젝트나 프레임워크로는 Unity, Unreal Engine, Godot 등이 있으나, Renderlet은 Wasm 기반의 경량화와 이식성에 더 중점을 둔 차별화된 접근 방식을 취하고 있음.
Hacker News 의견
  • PAL 단계를 건너뛰고 바로 SetupRuntime으로 넘어가는 것이 좋음. 비그래픽 개발자들은 이러한 사항을 잘 모르며, API에 불필요한 추가 단계를 만드는 것은 바람직하지 않음. PAL은 다른 곳에서 사용되지 않으므로, WebGPU를 사용하는 것이 좋음. (IPal은 IRuntime의 멤버여야 하며, WebGPU 컨텍스트에서 제거될 준비가 되어 있음).

    • 웹GPU 사용 권장: PAL 단계 생략, SetupRuntime 직접 시작, API 단순화 필요성, IPal의 IRuntime 통합 및 제거 대상.
  • 이 프로젝트는 플랫폼 간 GUI를 만들기 위한 멋진 위젯 키트와 상호작용 모델을 위한 놀라운 캔버스가 될 수 있음. C/C++ 백엔드와 WASM 타겟은 거의 모든 언어로 FFI를 구축할 수 있음.

    • 플랫폼 간 GUI 개발 가능성: 다양한 언어로 FFI 구축 가능, C/C++ 백엔드와 WASM 타겟의 장점.
  • 텍스트와 폰트 지원에 대한 계획이 궁금함. 일부 그래픽 엔진은 원하는 모든 방식으로 텍스트를 지원하지 않음. OTF나 WOFF2 파일을 로드하고 임의의 문자열을 표시할 수 있을지 여부에 대한 질문.

    • 텍스트 및 폰트 지원 문의: 다양한 텍스트 표시 방식 지원, OTF/ WOFF2 파일 로드 및 문자열 표시 가능성.
  • 프로젝트에 대한 큰 관심. 런타임, 이벤트 루프, FFI, 윈도우 포인터 소유권 등에 대한 몇 가지 질문이 있음. 오디오 플러그인과 VST에 대한 관심이 있으며, 이벤트 루프와 윈도우 관리에 대한 제약이 있음. JUCE는 사실상의 해결책이지만 오래되었고 불편함.

    • 오디오 플러그인과 VST에 대한 관심: 런타임, 이벤트 루프, FFI, 윈도우 관리에 대한 질문, JUCE의 대안으로서의 가능성.
  • 이 프로젝트는 정말 멋지며, 지난 몇 년 동안 꿈꿔온 것임. WASM은 그래픽/오디오/멀티미디어 계산의 휴대 가능한 단위로서 많은 잠재력을 가지고 있음.

    • WASM의 잠재력 강조: 그래픽/오디오/멀티미디어 계산을 위한 휴대 가능한 단위로서의 WASM의 가능성.
  • Godot Engine에서 WASM을 작동시키기 위한 작업을 진행 중임. Safari에서의 공유 배열 버퍼 접근성 문제와 온라인 게임에 중요한 광고 네트워크 접근 문제를 어떻게 극복했는지 궁금함. 단일 스레드 대 정규 빌드 문제를 지적함.

    • Godot Engine과 WASM 작업: Safari의 공유 배열 버퍼 접근성 문제, 광고 네트워크 접근, 단일 스레드 대 정규 빌드 문제.
  • 3D 그래픽/WASM 분야에서 더 많은 프로젝트를 보게 되어 기쁨. YC에 들어가기 위한 팁이 있는지 질문. Unreal Engine 5를 WebGPU와 WebAssembly로 포팅하는 작업을 수년간 진행해옴. 멀티스레드 렌더러와 자산 스트리밍 시스템을 가지고 있으며, 사용자가 전체 게임/앱을 미리 다운로드할 필요가 없음. 또한, 전체 애플리케이션을 한 번에 메모리에 올릴 필요가 없음. 개발자들이 온라인으로 프로젝트를 배포할 수 있는 전체 호스팅 플랫폼과 백엔드도 구축함.

    • Unreal Engine 5의 WebGPU 및 WebAssembly 포팅: 멀티스레드 렌더러, 자산 스트리밍 시스템, 전체 게임/앱 다운로드 불필요, 호스팅 플랫폼 및 백엔드 구축.
  • wasm I/O에서의 발표가 놀라웠으며, 이 작업이 주목받고 있는 것을 보게 되어 기쁨.

    • wasm I/O 발표에 대한 긍정적 반응: 발표의 인상적인 내용과 작업의 주목.
  • Flutter의 주요 개발자인 Ian Hickson의 기사를 읽었는지 질문. WASM을 사용하여 완전한 크로스 플랫폼 UI 프레임워크를 가질 수 있는 개념을 설명하고 있으며, 이는 Flutter가 사용하는 개념임.

    • Flutter와 관련된 WASM 사용: 크로스 플랫폼 UI 프레임워크 개념, Flutter와의 연관성.
  • CAD 커널에 대해 앱에 통합할 수 있는 manifold를 강력히 추천함.

    • CAD 커널 추천: 앱 통합을 위한 manifold 추천.