▲

GPU에서 선명한 텍스트 렌더링하기

 (osor.io)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 텍스트 렌더링의 품질 문제, 특히 SDF(거리장) 기반 방식의 한계를 해결하기 위해 새로운 실시간 벡터 렌더링 기법을 제안함
  • 글리프(문자)를 벡터 곡선 형태로 GPU에 직접 전송하여 실시간 래스터라이즈를 수행함으로써 무제한 해상도 및 적은 메모리 사용을 달성함
  • 텍스처 아틀라스 및 시간 누적(temporal accumulation) 기법을 활용해 높은 안티앨리어싱 품질과 효율적 캐싱을 실현함
  • 다양한 서브픽셀 구조(예: OLED, LCD 등)에도 맞춤 적용할 수 있어 프린징(색 번짐) 문제 없이 부드럽고 선명한 결과를 제공함
  • 실시간 텍스트, UI, 게임 등에서 고품질 글꼴 렌더링을 위해 단순하면서도 확장성 높은 접근법을 제시함

서론: 텍스트 렌더링의 고민

  • 실시간 텍스트 렌더링에서는 알리아싱(계단 현상), 대형 텍스처, 빌드 시간, 확대/축소, 부드러운 이동 등 다양한 문제가 존재함
  • 기존에 많이 쓰이는 Multi-Channel Signed Distance Fields(SDFs) 방식은 품질 및 유연성 측면에서 한계가 있었음
  • 최근 OLED 모니터의 비표준 서브픽셀 구조와 프린징 문제로 계기가 되어 서브픽셀 안티앨리어싱까지 고려한 새로운 접근법을 개발하게 됨

기존 SDF 방식의 한계

품질

  • SDF 방식의 경우 세밀한 디테일이나 얇은 획이 많은 글꼴에서는 품질 저하 및 정보 손실 문제가 발생함
  • 해상도를 높이지 않으면 특정 글리프에서 아티팩트가 남음

아틀라스 크기

  • SDF는 처음에 오프라인으로 만든 뒤 아틀라스를 저장하는데, 많은 글리프나 CJK(중국어, 일본어, 한국어) 폰트에서는 현실적으로 불가능할 정도로 커짐
  • 여러 폰트를 동시에 사용할 경우 메모리 소모와 스트리밍 대역폭 부담이 커짐

유연성 및 단순성

  • SDF라는 중간 단계를 거치기에 소스 데이터와 최종 결과까지 전체 흐름이 복잡해짐
  • 실시간 혹은 동적인 벡터 이미지를 바로 활용하거나 편집하는 데 제약이 큼

새 방식: 벡터 곡선 실시간 래스터라이즈

  • 텍스처를 미리 만드는 대신, 화면에 실제로 보이는 글리프의 벡터 곡선 데이터(베지에 곡선 등)를 직접 GPU로 전송하고, 그 자리에서 래스터라이즈
  • 아틀라스 텍스처에 필요한 만큼만 글리프를 넣으며, 사용 빈도에 따라 유지하거나 해제함
  • 글리프가 화면에 남아 있는 동안 표본 샘플의 누적(temporal accumulation)을 통해 매우 고품질의 좀 더 부드러운(anti-aliased) 결과를 구현함
  • 늘 벡터 기반으로 처리하기 때문에 해상도 제한 없이 선명한 결과를 제공함

글꼴 곡선 데이터 처리

  • FreeType 등 오픈소스 라이브러리로 다양한 글꼴 포맷을 읽고, 글리프의 곡선 정보를 추출
  • 글리프를 라인, 2차/3차 베지에 곡선 형태로 파싱하며, 모든 곡선을 2차 베지에 곡선으로 변환해 GPU 셰이더에서 처리 단순화
    • 라인은 중간 제어점을 추가해 2차 곡선으로 변환
    • 3차 곡선은 2개 분할된 2차 곡선으로 변환

커버리지(픽셀 내부 채움) 계산

  • 각 픽셀마다 가로 방향(ray)으로 곡선과의 교차점을 계산, winding number(누적 교차 수)를 통해 내부/외부를 판단
  • 수백 번의 표본(n회 누적 샘플) 을 합산하며, 일부 미세 오차는 최종 결과에 거의 영향 없음
  • 샘플 포인트 배치(quasirandom sequence) 기법으로, 매 프레임마다 다양한 위치에서 결괏값을 누적함

곡선 접근 최적화

  • 글리프를 수평 밴드(band) 단위로 분할, 밴드별로 관련이 있는 곡선들만 테스트하여 연산량 절감
  • 스레드 배치 및 밴드 단위 반복을 통해 GPU에서 벌크 연산 효율성을 극대화

아틀라스 패킹 및 관리

  • 아틀라스(공유 텍스처)에 각 글리프 이미지를 할당후 관리
    • 없는 글리프는 공간을 새로 할당해 래스터라이징, 이미 있는 글리프는 재사용
    • 참고로 같은 글리프라도 서브픽셀 포지션 및 크기에 따라 서로 다른 버전이 필요할 수 있음
  • Z-Order Packing(Morton code 등)을 통해 1차원 비트셋과 2D 공간 간 효율적 패킹 구현
    • 라틴 계열은 세로 기준, 아랍어 계열은 가로 기준 등 언어 구조별 유연한 응용 가능
  • 글리프가 더 이상 필요없어지면, 아틀라스 공간을 다시 할당해 사용

시간 누적(Temporal Accumulation)

  • 글리프 캐싱 및 표본 누적 방식을 통해, 표시 직후엔 빠르게 고품질 샘플 확보, 이후 프레임에서 더 정교하게 보정
    • 첫 프레임은 8샘플/픽셀, 이후 점차 샘플 수 감소, 최대 512회 누적
  • 부드러운 글리프 표시 및 리소스 최적화를 양립

서브픽셀 안티앨리어싱 및 프린징(Fringing) 방지

  • 서브픽셀(RGB 등 각 소자를 샘플로 간주) 단위로 렌더링 영역을 배분하여 수평 해상도 증가 효과 구현
    • LCD 표준 구조, OLED/WOLED 등 다양한 배열 지원
    • 프린징(색 번짐) 없는 부드러운 효과 지정
  • 서브픽셀 샘플이 중첩(Overlapping)되도록 배열 시 실제 모니터의 빛 혼합 효과까지 반영
  • 픽셀 경계나 힌팅(hinting) 없이도 자연스럽고 선명한 출력 가능

디스플레이별 서브픽셀 구조 접근의 중요성

  • 모니터의 서브픽셀 배열 정보를 프로그램적으로 확인 가능하다면 훨씬 정교한 렌더링이 가능
  • 하드웨어의 한계가 아니라 소프트웨어 처리의 문제임을 강조

마무리 및 활용 전망

  • 좋은 텍스트 렌더링이 전체 사용성 및 서비스 품질에 미치는 영향이 큼
  • 특히 UI/게임 등에서 고품질 글꼴 표현이 제품 경험에서 큰 차이를 만들 수 있음
  • 단순·확장성·고품질·유연성이라는 원칙을 실현할 수 있는 작업 구조임
  • 오픈소스 구현, 다양한 서브픽셀 대응 등 실제 산업/프로덕션 활용에 매우 적합함
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • 글 작성자인 나, 이렇게까지 글이 화제가 될 줄은 몰랐다. 흥미로운 대화에 참여해 주신 모든 분들께 감사 인사
  • 첫 영상에서 이탤릭체 "j"의 점이 사라진 이유에 대한 질문
  • 서브픽셀 폰트 렌더링은 가독성에 매우 중요하다는 의견. 하지만 저자가 지적했듯 현재 디스플레이 표준으로는 정확한 픽셀 레이아웃 사양을 얻을 수 없어 아쉽다는 생각
  • 이건 표준 해상도 디스플레이에서만 필요한 요소라 생각. 사실 필수까지는 아니고 있으면 좋은 정도 느낌. 이제 레티나 급 디스플레이가 보편화되어 굳이 서브픽셀 렌더링이 필요하지 않은 환경이 되었단 입장. 오히려 한때 LCD 시대에 등장한 임시적 혁신이었고 이제는 시대에 뒤처지는 느낌. 스크린샷의 서브픽셀 레이아웃 의존, 비트맵 확대 불가 등 부작용이 꽤 많다. 그래서 Apple이 이 방식을 macOS에서 아예 없앤 배경이 있다 생각
  • DisplayID 같은 표준이 이런 레이아웃 정보를 제공하도록 설계되었다는 점을 지적. 제조사들이 잘 구현을 안 하거나 DB에 저장이 안 될 뿐, 인기 많은 디스플레이 모델이라면 하드웨어 정보 DB에 기록하고 활용할 수 있을 거란 입장. DisplayID 위키 참고
  • 서브픽셀 구조의 다양성을 수십 년간 알고 지냈다는 아쉬움과, 원문이 잘 정리해준 점을 평가. 그리고 ‘서브픽셀 동물원’으로 불리는 예시 페이지 공유 subpixel zoo
  • ‘비극’까지는 과한 표현이라 생각. 각 OS가 이전 Windows의 ClearType 튜너처럼 디스플레이별로 세부 조정을 할 수 있는 기능만 넣어줘도 충분하다고 봄. 모니터가 정보를 잘못 보고할 때를 대비한 사용자 설정 기억도 필요
  • 서브픽셀 렌더링이 대부분 언어에서 꼭 필요한 건 아니란 입장. 안티앨리어싱 없는 비트맵 폰트나 힌팅된 벡터 폰트만으로도 읽기 편함. 다만 한자나 일본어 같이 복잡한 문자를 사용하는 언어에서는 좀 더 중요성 있음
  • GTK4가 GPU 중심 렌더링으로 전환하며 RGB 서브픽셀 렌더링을 포기한 배경이 GPU 기술과 연관되었다는 내용. 하지만 원문에서 GPU로도 가능함을 보여준 만큼, 혹시 다른 이유나 단점, 혹은 스택 통합의 어려움이 있었던 게 아닐까 하는 추측
  • Cosmic Text(Cosmic DE)가 Swash를 통해 GPU 상에서 서브픽셀 렌더링을 지원하는 가능성 언급
  • SDF와 MSDF를 WebGL/WebGPU에서 구현하는 법에 관심 있다면 내가 직접 쓴 튜토리얼 참고 추천 튜토리얼 링크
  • Rust로 구현된 WebGPU(WGPU)에 관심이 있다고 언급. 본 튜토리얼이 고급 과정에 가깝다고 느꼈고, JS 예제를 Rust로 바꿔보며 배우는 게 효과적이었다는 경험 공유
  • 사이트 포맷이 매우 마음에 들어 나도 GPU 관련 튜토리얼을 이렇게 만들고 싶다 밝힘. 혹시 이게 특정 템플릿인지, 코스 일부인지 궁금
  • Slug 라이브러리는 GPU 글리프 래스터라이저를 구현한 상용 미들웨어라는 정보 공유 Slug Library
  • Slug 웹사이트에서 꽤 자세히 알고리즘을 공개하고 있어 흥미롭다는 생각. 혹시 특허가 있는지 궁금. Cosmic-text로 폰트 파싱/레이아웃 활용해 오픈소스 wgpu 버전 만들면 재밌겠지만 나중에 Slug에 소송당하면 곤란할 거라는 우려
  • 이 분야에 익숙하지 않은 사람들을 위해 SDF 텍스트 렌더링의 히스토리와 현주소를 요약. Valve가 2007년 SDF 기반 아키텍처를 선보였고, 이후 2012년 Glyphy(비대드 에스파보드)가 GPU 기반 SDF 구현을 내놓으면서 변화가 있었지만 주류 OS나 웹브라우저는 여전히 1990년대식 Truetype 방식에 머무름. 이 방식은 작고 가벼우나, 서브픽셀 정렬/아비트러리 레이아웃을 지원하지 않고, 텍스트 확대나 3D 변형에도 큰 제약이 있다. 이런 기술 진화가 더딘 것은 위험 대비 이득이 크지 않고, 렌더링뿐만 아니라 줄 바꿈 등 복잡한 레이아웃 처리까지 GPU/CPU 협업이 힘들기 때문일 것 같다는 생각
  • 줄 바꿈 등 텍스트 레이아웃 작업은 실제로 렌더링과 거의 별개라는 지적
  • Servo의 Pathfinder는 GPU 컴퓨트 셰이더를 이용해 훨씬 더 나은 성능의 GPU 텍스트 렌더링을 이미 구현한 예시라는 소개
  • 웹킷의 GPU 텍스트 렌더링 방식 관련 기사 링크. 현재 단계에서도 문자열~비트맵까지 어느 정도 GPU 상에서 처리가 가능하나, 기대하는 ‘서브픽셀 안티앨리어싱’이 GPU 프로모션 시엔 빠진다는 지적
  • 실제로 Windows뿐만 아니라 Chrome/Firefox에서도 이미 수년 전부터 서브픽셀 안티앨리어싱까지 GPU 가속이 있었다는 사실 언급. 최신 기술이 안 쓰인다는 건 오해라는 점 강조
  • 간결한 개요를 잘 정리해줘서 고맙다는 코멘트
  • 서브픽셀 렌더링을 원한다면, 디스플레이의 서브픽셀 그리드를 정확히 파악해야 한다는 전제. 모니터마다 별도 설정 요청이 유일한 합리적 UX라는 의견. OS가 화면 회전 등까지 처리해야 함
  • 저자 의견처럼 디스플레이가 시스템에 자신의 서브픽셀 구조를 직접 알려주는 방식이 가장 이상적이라는 생각
  • 뛰어난 결과라는 평가와 함께, 서브픽셀 안티앨리어싱은 2000년대 초 LCD 시절 명확한 장점이 있었지만 고해상도 레티나 디스플레이 시대엔 무의미에 가깝다고 판단. 단점으로 불투명 배경만 적용 가능, 후처리(리사이즈, 미러링, 블러 등) 불가, 스크린샷이 다른 기기에서 어색하게 보이는 점 등을 꼽음
  • 서브픽셀 AA를 없애면 단순화는 되지만, 아직 저해상도 96dpi, 1366x768 디스플레이 기반의 데스크탑 사용자도 많다는 데이터(파이어폭스 하드웨어 서베이 자료) 제시
  • 고해상도 화면 사용자로서 저해상도 사용자까지 고려하지 않는 건 무책임하다는 의견도 덧붙임
  • 서브픽셀 레이아웃 프로토콜이 도입되어도 일부 제조사가 잘못 구현해, 일반 사용자가 이해하기 어려운 렌더링 문제가 생길 수 있다는 우려
  • 손글씨체(커서체)를 보고 든 첫 생각이 “대체 이딴 커서체를 누가 좋은 아이디어라고 생각했을까”라는 솔직한 감상
  • 손글씨, 특히 깃펜이나 만년필을 사용하던 시대에 손글씨 쓰던 사람들이 좋아했을 거라는 설명
  • 편지를 많이 쓰던 사람들이 커서체를 사용했으며, 인터넷과 장거리 무료 통화가 등장하며 커서체 사용이 줄어들었다는 해설
  • 코드 링크를 찾을 수 없다는 질문
답변달기