글 작성자인 나, 이렇게까지 글이 화제가 될 줄은 몰랐다. 흥미로운 대화에 참여해 주신 모든 분들께 감사 인사
첫 영상에서 이탤릭체 "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 디스플레이 기반의 데스크탑 사용자도 많다는 데이터(파이어폭스 하드웨어 서베이 자료) 제시
고해상도 화면 사용자로서 저해상도 사용자까지 고려하지 않는 건 무책임하다는 의견도 덧붙임
서브픽셀 레이아웃 프로토콜이 도입되어도 일부 제조사가 잘못 구현해, 일반 사용자가 이해하기 어려운 렌더링 문제가 생길 수 있다는 우려
손글씨체(커서체)를 보고 든 첫 생각이 “대체 이딴 커서체를 누가 좋은 아이디어라고 생각했을까”라는 솔직한 감상
손글씨, 특히 깃펜이나 만년필을 사용하던 시대에 손글씨 쓰던 사람들이 좋아했을 거라는 설명
편지를 많이 쓰던 사람들이 커서체를 사용했으며, 인터넷과 장거리 무료 통화가 등장하며 커서체 사용이 줄어들었다는 해설
Hacker News 의견