Duxel은 앞전에 MewUI의 동작성에 자극을 받아 평소에 만들고 싶었던 Dear ImGui 스타일의 GUI 라이브러리입니다. 관련된 정보는 아래의 링크를 통해 확인할 수 있어요.
100% 바이브 코딩으로 진행하고 있으며 GPT-5.2-Codex → GPT-5.3-Codex 모델로 GitHub Copilot을 이용해 만들고 있습니다.
슬로그를 통해 달성하고 싶은 계획은 다음과 같아요.
좀 더 사용하기 편한 구조로 변환 (취소)
Duxel은 별도의 렌더 트리가 없어요. 그래서 WinForms나 WPF에 익숙한 분께는 거칠어요. 그냥 OnRender 메소드에서 일일이 화면에 그려서 구성하는 방법이기 때문이에요.
그래서 Fluent API를 이용해서 선언적인 구조로 변경하려고 했습니다만…
꽤 긴 삽질을 한 이후에 이런 디자인이 ImGui 스타일과 맞지 않다는 결론에 도달했습니다. 그래서 취소
→ 이것보다 DSL 문법을 적극 활용하는 방법으로 고도화 하려고 합니다.
모든 위젯의 동작성 확보
대부분의 위젯이 잘 동작하지만 위치가 이상하거나 오동작 하는 위젯이 상당히 있습니다. 이를 보정하는 작업입니다.
깔끔한 글자 출력 및 속도 보장
Vulkan을 직접 다루다 보니 DirectWrite 수준의 글자를 출력하기가 정말로 어렵더라고요… 관련 전문 지식도 없었던지라 엄청난 삽질 이후 DirectWrite를 추가하게 되어 구조적인 문제가 현제는 있습니다. 관련해서 Chromium 수준의 폰트 렌더링을 확보하는 것입니다.
그 다음은 크로스플랫폼
Duxel은 원래 크로스플랫폼 용 라이브러리를 위해 시작하였어요. 그런데 아직은 Windows에서만 동작합니다. 리눅스 및 iOS에서 동작하도록 확장할 예정이에요.
Silk.NET의 의존성 제거
Vulkan의 기능을 이용하기 위해 Silk.NET을 썼지만 알기로는 NativeAOT와 친화적이라고 알고 있었는데 Trim이 안되는 사소한 문제가 있어서 최종 실행 파일 크기가 4MB를 넘는 문제가 있습니다. Silk.NET를 걷어내서 3M 미만으로 실행파일을 줄이는 것이 목표입니다.
결국엔 뭘 하고 싶은거지?
MewUI가 Window Forms 및 WPF의 굴레에서 벗어나 크로스플랫폼으로 NativeAOT의 장점들을 활용할 수 있게 된 것 처럼
Duexl은 고속/실시간 2D 렌더링이 필요한 다양한 목적에 활용할 수 있도록 발전할 예정입니다.
그런데 바이브코딩을 해도 상당한 시간과 노력이 들어가는 것은 당황스럽네요 ^^;