GPUで文字がくっきり！鮮明レンダリング技術
引用元：https://news.ycombinator.com/item?id=44265233
著者だよ！まさか記事がここに載るとは思わなかった。読んでくれて、面白い議論に参加してくれて、本当にありがとう！
すごくいい記事だね！最初の動画の、斜体の“j”の点、どうなったの？
ありがとう！よく気づいたね。あれはね、あの点の輪郭の点が、フォントの他の曲線と逆方向に定義されてるからなんだ。だからレンダラーが外側の輪郭じゃなくて内側の輪郭として解釈しちゃう。
TrueType（外側が時計回り）かPostscript（外側が反時計回り）で向きが決まってるんだけど、Postscriptスタイルを見つけたら反転させて、レンダラーが同じように処理できるようにしてるんだ。でもなぜか、あの点はFreeTypeで反転を避けてるか、元のフォントファイル自体がおかしいか。
多くのレンダラーは輪郭の向きを気にしないけど、それもそれで問題（変な場所が塗りつぶされたり）があるから、どっちもどっちって感じかな。Sebastian Lagueのテキストレンダリングのすごい動画でも、これに対処してたと思うよ。
元のフォントファイル（Libre Baskervilleはオープンソースだから）を見て、何がおかしいのか確認してみようかな。もしそのレベルの不整合なら、直せるかもね。ナイスな発見！
サブピクセルフォントレンダリングは可読性には必須だけど、著者が指摘するように、既存のディスプレイ規格がピクセルレイアウトの仕様を提供してくれないのは悲劇だね。
標準解像度ディスプレイだけだね。それも“必須”じゃなくて、あるといいねくらい。世界はRetinaみたいなディスプレイにどんどん移行してるし、そこでサブピクセルレンダリングが必要な理由はほとんどない。
それに、スクショが特定のサブピクセルレイアウトに縛られたり、Bitmapを拡大できなかったり、たくさんの問題があるしね。CRTとRetinaの間のLCD時代の、一時的なイノベーションだったんだよ。今となっては時代遅れ。AppleがmacOSから何年も前に削除したのにはちゃんとした理由があるんだよ。
標準解像度で標準的なサブピクセルレイアウトのディスプレイでも、サブピクセルレンダリングで色ずれが見えるんだよね（カラーフリンジング）。HiDPIディスプレイはスマホ以外どこにも持ってないけど、それでもサブピクセルテキストレンダリングはいらない。みんなあれを万能薬みたいに言うけど、正直、あれに行き着いた経緯って結構特殊でちょっと変なんだよ。
サブピクセルレンダリングで色ずれが見えるって？ディスプレイのRGBサブチャンネルごとにガンマ調整してみた？サブピクセルアンチエイリアシングは、他の種類のアンチエイリアスよりもさらに正確な色空間情報に頼ってるんだよ。
世界がRetinaに移行してるって？俺の世界じゃ違うな。クリスピーな仕事用MacBookに繋いでるディスプレイもまだ1080pだし（macOSだとすごく変に見えるけど）。技術系の知り合いでも、ほとんどが1080pノートだよ。世界はみんなが思ってるほどRetinaじゃない。
なんか理由があって、テレビじゃないと1080pから4kに結構な値段が跳ね上がるんだよね。パネルがもっと高いのはわかるけど、メーカーが本当に倍も払ってるかは疑問だな。
俺のデスクトップモニターは47インチのディスプレイ… 4kで動かしてるよ。基本的にテレビをコンピューターモニターにしたもの。デスクの全幅を占めてる。
プログラミングにはとてつもなく素晴らしいディスプレイだよ。コードを3列フル幅で並べられる。あるいは2列とターミナルウィンドウ。
でもピクセルはまだ“普通”のサイズ。テキストはサブピクセルレンダリングがあると目に見えてシャープに見えるんだ。サブピクセルレンダリングが複雑で正しく実装するのが難しいのはわかるけど、いい技術だよ。このサイズで同じくらいきれいなテキストレンダリングをするには、8kディスプレイが必要になる。それだと値段がずっと高いだけじゃなく、8k画像をレンダリングしたら、どんなコンピューターもほぼ悲鳴をあげるだろうね。
サブピクセルフォントレンダリングを終わらせるのは早すぎるよ。いいものだし、まだ必要だ。
このメッセージを読んでる4k（3840x2160 UHD）モニターは、10（10）年前に250usdで買ったやつだよ。
同じ年に800usdで買った、ほぼあり得ない（50インチ？正確には覚えてない）4k TVを失ったことを今でも嘆いてる。当時あった他のどの4kモデルも3.3k usd以上だったのに。
その黒点は「黒フレームをレンダリングすると、セットが100%電源オフに見える」で、白点は「おめでとう、これが野球場の投光器を凝視する様子だ」って感じだった。当然10%の明るさで使ってたけど、適当なコンテンツを再生するだけで、夜のリビングとダイニングを合わせた部屋の他の照明は全く不要だったくらいだ。
この世には純粋すぎたんだ… 子供の一人がリビングで何か投げて壊しちゃったんだよ。:(
MacOSって、非Retinaディスプレイだと見た目が悪いんだよね。テキストにサブピクセルAA使わないのが原因かな。
知ってる限りだと、MacOSが標準解像度で見づらいのはグリッドフィッティングしないのが主な理由じゃないかな。俺はLinux使ってて、サブピクセルAAは使ってないけど（通常のAAだけ）、グリッドフィッティングをしっかりやってるから文字がシャープだよ。
Appleはハードウェア全部自分で作ってるから、みんな特定の機能を持ってるって前提で開発できるんだよ。持ってない人は気にしない。他のメーカーにはそんな特権ないもんね。
Appleならエコシステム全体の画面で特定のサブピクセル配列を簡単に統一できたはずなのに、それでもその機能をやめちゃったんだよね。
ピクセル密度が高くてグレースケール表示で十分綺麗なら、サブピクセルAAで発生するアーティファクトなんて要らないし馬鹿げてる。それにディスプレイのスケーリングと組み合わせるとサブピクセルAAは余計なノイズを生むんだよね。（まあスケーリング自体も綺麗じゃないけどね。例’えばiPadのスケーリングのノイズは耐えられないな）
Appleはピクセル密度が十分高いことを保証できないよ。だってどんな外部モニターにも繋がるPCやタブレット作ってるじゃん。MacOSって218ppiじゃないとマジひどい見た目なんだよね。Appleの高いディスプレイ以外でこれ満たすのって、LGのUltrafine 5KとDellの6Kだけ。LGはもう売ってないらしいけど。
つまり、LGかAppleの高いディスプレイ買わないと外部モニターでのMacOSは最悪になる可能性が高いってこと。接続設定の酷さとか、BetterDisplay買わないとリフレッシュレート選べないとか、そういう問題もあるしね。
でも、世界中のディスプレイ全体で見たら、Retinaタイプって何%くらいあると思う？全然普及してないんじゃない？
面白いことに、それって当たってる部分があるんだよね。今のスマホは全部Retinaだし、安いタブレットですら高解像度。俺が持ってるので一番解像度高いのってGalaxy Tab S7 FEかも。なのにPCは高いの買わないと1080pのまま。大手メーカーがケチってるだけだと思うんだよね。だってChromebookくらいの値段で高解像度タブレット出てるのに、PCに同じの載せるのに500ユーロも値上げする必要ないでしょ。
＞スクリーンショットが特定のサブピクセル配列に縛られる、みたいな話’だけど、スクリーンショットはもっと良い画像形式が欲しいよね。ラスタライズじゃなくてベクトルとかテキスト情報ごと保存できるやつ。WindowsのHDRスクリーンショットも似た理由でダメになってるし。
または、単純にスクリーンショットを水平方向の解像度を3倍にして、ピクセルアスペクト比を3：1で保存するとかどう？
DisplayID 標準 (EDID の後継) って、このためにあるはずじゃない？
https://en.wikipedia.org/wiki/DisplayID#0x0C_Display_device_…
メーカーがこれ実装してないだけ？
どっちにしても、簡単に情報取って hardware-info database に入れられるはずなのにね、少なくともよくあるディスプレイモデルなら。
OS がこれ用の API を公開してるとは思えないなー。
Linux tool で画面の明るさ変えるやつ、GPU 経由で hardware に direct に話しかけてるし。
Unfortunately、EDID も always 信頼できるわけじゃないんだよね。向き知らないと rotated screens が awful になるし。
必要な data を取るには administrator access がいるだろうし、 security とか ease-of-use の問題にもなるかも。
Plus、vendor によっては EDID に lie するみたい。ACPI みたいな他の情報 tables と同じで、別の product の config を copy して、覚えてる metadata だけ update して出荷してる感じ。
なんで？ decades 前からあったのに :(.
記事は excellent だし、この ”subpixel zoo” も面白いよ。
https://geometrian.com/resources/subpixelzoo/
“Tragedy” はちょっと overstate じゃない？
各 OS が Window の former ClearType tuner みたいなの提供して、 screen や monitor model ごとに results を覚えればいいじゃん。
monitor が間違った layout を report する inevitable case のためにも、それが desirable だと思うよ。
Subpixel rendering って most languages では unnecessary なんだよね。
Bitmap fonts や hinted vector fonts を antialiasing 無しで使えば excellent な readability が得られるよ。
Chinese や Japanese みたいに very intricate details を持つ characters を使う言語の場合だけ important。
GTK4 は rendering を GPU に move して RGB subpixel rendering を give up したんだ。
GPU-centric な decision で impractical になったって聞いたけど、article は possible って示してるね。
So perhaps、GTK の reason は another one だったか、presented solution が disadvantages を持ってたか、just not integrate in the stack だったのかも。
Cosmic Text (Cosmic DE) は swash 経由で GPU 上でこれやるかもね。
Subpixel rendering があるよ。
SDF と MSDF を WebGL / WebGPU で implement する方法に interest があるなら、この tutorial を take a look してみて。
https://infinitecanvas.cc/guide/lesson-015#msdf.
This looks great。
Rust の WebGPU implementation である WGPU に some interest があって、この tutorial は advance course みたい。
JavaScript examples を Rust に translate するの、learning に ideal なんだ。
code を copy/paste できないけど、APIs は enough に近いから port しやすいし、WGPU docs に慣れる excuse になるよ。
わー、サイトの形式めっちゃ好き！もっと詳しく教えてくれる？ GPUチュートリアル作るの好きなんだ。あなたのサイトみたいに構成したいんだよね。既存のテンプレートなのかな？ それとも何かのコースの一部？
もっとコメントを表示（1）
サイト形式はVitePressのdocsテンプレートを再利用してるみたいだね。テキストが多いコンテンツにはすごく良い方法だよ。サイトはオープンソースみたいで、ページの一番下にリポジトリへのリンクがあるよ：https://github.com/xiaoiver/infinite-canvas-tutorial
僕はVitePressを使ってるよ。組み込みのMarkdown拡張機能がいっぱいあるんだ。
https://vitepress.dev/guide/markdown
Slugライブラリ[1]は、こういうGPUグリフライスタライザーを実装した商用ミドルウェアだよ。[1]: https://sluglibrary.com/
彼らはウェブサイトでアルゴリズムをかなり詳しく説明してるね。特許持ってるのかな？ オープンソースのwgpu版を作るのは面白そうだけど、フォント解析とかレイアウトにcosmic-textの何かを使うとか。でも、最後にSlugから訴えられたら、全然面白くないな。
Slugは特許取られてるけど、vello（wgpuを使うやつ https://news.ycombinator.com/item?id=44236423）みたいに他の似たアプローチも開発中だよ。
私もglyphon（https://github.com/grovesNL/glyphon）作ったよ。wgpuとcosmic-textを使って2Dテキストをレンダリングするやつ。動的なグリフテクスチャアトラスを使ってて、ほとんどの2Dユースケースでは実際うまくいくよ（本番環境で使ってる）。
cosmic-textとgliumで似たようなことしたことあるよ。でも、ゲームとか3D用に、グリフのアウトラインとか変換でもっと凝ったことできるベクトルレンダリングモードがあると面白いよね。もちろんオープンソースで。
velloはその方向に向かってると思うけど、試すたびにいつもなぜかサンプルが壊れてたんだ。
似たようなことの放棄した概念実証（Proof-of-Concept）があるんだけど、チェックしてみる価値あるかも https://github.com/mxple/fim
超面白い！動画で見た感じだと、乗り物酔いしそうかなと思ったけど、ベジェレンダリングで何を目指してるかは分かったよ。
GPUがほぼ無限の頂点／ピクセル描画能力を持ってるのに、なんでテキストをオフラインでレンダリングして、SDFみたいなトリックと一緒にアトラスに格納する必要があるのか、まだよく分からないんだ..。記事でもグリフ曲線をアトラスに書き込むって言ってるし。なんでシェーダーで直接テキストをレンダリングできないの？ ベジェを三角形メッシュに変換する方法はあるはずだよ。
今CADアプリ用のGPUテキストレンダラーに着手しようとしてるんだけど、その理由がすぐに分かるといいな。
同じ文字を繰り返し描くなら、その結果をキャッシュしとく方が大抵の場合、断然安いよ。GPUは確かに速いけど無限じゃないし、事前に描かれたテクスチャからサンプルするのとか超得意だからさ。
あと、速さだけじゃなくて電力消費も重要なんだよね。モニターのリフレッシュレートに達するくらい速くなれば、それ以上速くなっても体感の応答性は変わらないかもだけど、バッテリーは長持ちするようになるかも。
だから、レンダリングにおいては「速すぎる」ってことはないんだ。もっと速くすれば常に何かしらメリットがあるんだよ。
＞モニターのリフレッシュレートに達するくらい速くなれば、それ以上速くなっても体感の応答性は変わらないかも
これは正しくないね。もしレンダリングがもっと速ければ、描画開始や入力処理のタイミングをフレーム表示時間にギリギリまで近づけられるから、入力の遅延を減らせるんだよ。
それは本当だけど、実際にはあんまり実装されてないんだよね。
それは確かにそうだけど、今回のケースでは、描画済みの文字の出力をキャッシュして再利用できるんだよ。SDFとかの中間ステップもすっ飛ばせる。
もちろん、ゲームとかでフォントサイズが変わったり、文字が回転・傾いたりすると、この方法は使えなくなるけどね。
普通の表示サイズでも、フォントの三角形密度ってめちゃくちゃ高いんだよね。最近のGPUアーキテクチャは、そんな高密度の形状を扱うのがめっちゃ苦手なんだ。
こういう場合、単純にGPUに三角形をバンバン送るより、アトラスとか別のやり方の方がずっと効率的。
ほとんどのGPUはピクセルシェーダーを4つ一組で処理するんだけど、三角形が全部1ピクセル大だと、3つのスレッドが視覚的に何も貢献しない無駄になるんだよ。これを’quad overdraw’って言うんだ。
頂点処理にも無駄な時間をたくさん費やすことになるんだよね。
GPUは無限に頂点やピクセルを描けるわけじゃないからね。テキストを直接レンダリングするのは、単純にコストが高いんだ。
もちろん、やろうと思えばできるけど、フレームの描画に使える時間を食っちゃうし、電力消費も増えるだけで、特に良いことはないんだよ。
これをさらに詳しく言うと、GPUは三角形しかラスタライズできないから、文字をそのまま直接描くってことができないんだ。
シェーダーの中でラスタライズ処理を実装するか、フォントの滑らかな曲線を、結果が変わらないくらい十分な数の三角形に変換してあげる必要があるんだ（必要な三角形の数はフォントのピクセルサイズが大きくなるほど増えるよ）。
三角形を使うのは間違った選択だけど、それ以外は良い指摘だね。
この記事の人がアトラスを使ってるのは、ベジェ曲線をピクセルあたり最大512サンプルでスーパーサンプリングしてるからで、これがすごくコストがかかるんだ。
だけど、例えばベジェ曲線の領域とサブピクセルの領域が交差する部分の積分を計算する方が、はるかに速くリアルタイムで実行できる可能性があるし、スーパーサンプリングよりも正確だと思うよ。
GPUはすごく速いけど、完全に無限じゃないからさ。テキストにGPU時間を使っちゃうと、他の処理に回せなくなるんだ。
そして、ほとんどの場合、他の処理にGPU時間を使いたいものなんだよね。
それに、要求するGPU時間が多いほど、必要な最低ハードウェアのスペックも上がっちゃう。
文字ってクールで重要だけど、ユーザーとかお客さんを失うほど重要じゃないかもしれないからね。
Adaptive distance fieldsっていうのは、Saffronっていうフォントレンダリングライブラリで使われてた、古いけど興味深い技術だったね。
今でもすごく有効だし、オープンソースでの実装が期待されてる。
ADFっていう言葉はあまり広まらなかったんだけど、ほとんどが特許でガチガチに守られてたんだ。でも、もうほとんどの特許が期限切れになってるみたいだよ。
＞なんでシェーダーは直接テキストをレンダリングできないの？
https://sluglibrary.com/はDynamic GPU Font RenderingとかAdvanced Text Layoutを実現してるよ。
GPUラスタライザはサブピクセルレンダリングしないんだよね。これは3Dではいいけど、小さいテキストだと追加解像度を活かしたいじゃん？
でも、どうせアトラスにレンダリングするなら、別にGPUでやる必要なくて、FreeTypeみたいな既存のソフトラスタライザでアトラス作ればいいだけだよ。
＞綺麗だけど非標準サブピクセル構造でフリンジ問題がある新しいOLEDのことだね。
俺の理解だと、それより酷いよ。非標準なだけでなく、互換性のない複数のサブピクセルレイアウトがあるんだ。だからFreeTypeはOLED向けサブピクセルレンダリングを実装しなかったし、テキスト作業するならOLEDを避ける理由になってる。FreeTypeに限らず、QtやGTKみたいなGUIツールキットも対応しないといけない。
解決に進展があるかは不明。
＞モニターの任意のサブピクセル構造にアクセスできたらいいのにね、共通ディスプレイプロトコル経由で。
うん、そこはいい指摘だね。たぶんEDIDsで伝達されるべきかもね。
標準的なサブピクセルレイアウトのOLEDもあるよ。例えば俺のノートPCは縦の(!) BGRレイアウトで、FreeTypeとKDEは問題なく対応してる。変なレイアウトはたぶんHDRディスプレイで特定の色（青）が早く焼き付かないように、色ごとにサイズを変える必要があるからだと思うな。
そうかもね、でも俺が見たバグ報告だと色んなレイアウトがあって、どれも標準には見えなかったよ。Steam Deck OLED、LenovoノートPC、LG UltreaGear OLEDとかが例だね。共通点は正直見当たらないな。
* https://bugs.kde.org/show_bug.cgi?id=472340
* https://gitlab.freedesktop.org/freetype/freetype/-/issues/11…
理論上はそうだろうけど、実際には俺は4K OLEDディスプレイでコード書いてるけど、何もアーティファクトに気づいたことないんだよね。
高解像度だと問題が見えにくくなるだけかもね、でも問題自体はあるよ。
すごい仕事だね！この分野に詳しくない人向けに言うと、Valveがゲーム向けにSDFテキストレンダリングを発明したんだ。2007年に画期的な論文出して、今でもゲームで人気の技術だよ。2012年にはBehdad EsfahbodがOpenGL ESを使ってGPUで動くGlyphyっていうSDF実装を書いた。パフォーマンスや素早いテキスト変形を可能にしたことで賞賛されたけど、広くは使われてない。今のOSやブラウザはこれらの技術を使ってなくて、1990年代のTruetypeラスタライズに頼ってる。これは軽くて効果的だけど、多くの機能がないんだ。記事で示されてるようなサブピクセルアライメントや任意のサブピクセルレイアウトはできないし、ズームは重いし、スキューや回転、3Dみたいな複雑な変形はテキストレンダリングエンジンじゃできない。回転や変形が必要ならビットマップのリサンプリングになっちゃうけど、それは小さくて読みやすさを保つ特徴を全部壊して見た目が悪くなる。
なんで進歩がないかって？たぶん、得られるものに対して作業量とリスクが大きすぎるんじゃない？現代のウェブブラウザエンジンをGPU高速化テキストレンダリング使うように書き直すの想像できる？気が遠くなるような作業だよ。グリフのレンダリングはともかく、改行はどうする？CPUとGPUの間の大量の通信が必要そうだし、ソフトウェアとGPUの深い連携も難しいだろうね。
「GPUで文字レンダリングって、ラインブレークとかどうすんの？」って言ってるけど、テキストの形を整えたり改行したりって、描画とはほぼ関係ない話だよ。なんでそんなこと言うの？
ブラウザエンジンをGPUレンダリング用に書き換えるのって大変？
ServoのPathfinderっていうのがGPUのCompute Shaderでやってるよ。SDF使うよりずっとパフォーマンスいいんだ。https://github.com/servo/pathfinder
ちょっと補足すると、WindowsやChrome、Firefoxでは文字レンダリング、例えばSubpixel Antialiasingとかも、昔からGPUで加速してるんだ。Safariもたぶんそう。技術が進んでないってのは違うよ。
もっとコメントを表示（2）
SDFは万能じゃないよ。SDFは文字の輪郭からの距離をデータにする技術で、拡大縮小に強い。でも、使う文字すべてのデータが必要だから、Unicode全部に対応しようとするとデータがデカすぎる。だからOSやブラウザには向かないんだ。Emojiみたいなカラー文字も苦手だし。ゲームみたいに使う文字が決まってる場合に合う技術だよ。
俺の理解だと、記事の筆者のアプローチはSDFの問題とは違うんじゃないかな。使う文字のグリフだけをGPUに送る方式だから。フォントごとに事前計算は必要だけど、それは問題ないはず。
でもさ、前のコメントはブラウザの話をしてるんだよ？ブラウザはウェブページが指定するフォントを使うのに、どうやって事前にフォントを計算しとくの？
ウェブフォントでよくやるのは、フォントを読み込んでその場でSDFのデータを作る方法だよ（Troikaっていうライブラリとか）。最初の表示は少し遅くなるけど、数百ミリ秒くらいだから、ウェブで3Dレンダリングするなら誰もそんなに気にしてないんじゃない？https://github.com/protectwise/troika/blob/main/packages/tro-three-text/src/worker/SDFGenerator.js
「最初のレンダリングが遅れる」って話だけど、キャッシュすれば簡単に解決しない？同じサイトなら使うフォントはそんなに多くないし、頻繁に変わることもないと思うんだけど。
WebAssemblyを使って、Web workerの中でFreetypeっていうライブラリを動かせばいいんだよ。そんな難しくないと思う。
テキストが来たときに、必要に応じてSDFを用意すればいいんじゃない？現実的に考えて、日本語とか中国語（CJK）でも数千文字くらいあれば十分カバーできるはずだよ。
SDF生成ってGPU使えないとマジ遅いんだよね。速いアルゴリズムだとバグることもあるし。技術的な課題だね。
モダンなWebブラウザエンジンをGPUテキストレンダリングに書き換えるなんて想像できる？
これって、もう既に部分的にやってるんじゃない？このURLの記事（2014年）によると、ChromeとかSafariで要素をGPUに上げるとサブピクセルアンチエイリアスは失われるけど、グレースケールでレンダリングされるって。
じゃあ、何が足りないんだろ？UTF-8文字列からビットマップへの変換の一部はGPUでできるんじゃないの？https://keithclark.co.uk/articles/gpu-text-rendering-in-webk…
問題はサブピクセルレンダリングそのものじゃなくて（GPU compute shaderでやればピクセルパーフェクトも可能）、TrueTypeやOpenTypeの複雑なソフトウェアヒンティングが失われることなんだよ。でも、GPUでフォントをレンダリングする目的って、滑らかなアニメーションをサポートすることでしょ？ソフトウェアヒンティングされたフォントは静的にピクセルやサブピクセルグリッドにスナップされちゃうから、そもそもこの二つの使い方は相容れないんだよ。
解説ありがとう！こういうサクッとした概要を読むの、大好きだよ。
複雑な変換（スキュー、回転、3D変換）はできない
いいね！俺のテキストドキュメントビューアは、左から右への直線描画だけで十分なんだよ。右から左もほぼ同じくらい簡単だろうし。そういえば、中国語ってまだ上から下がいいのかな？
俺のテキストドキュメントビューアは、左から右への直線描画だけで十分なんだよ。
「テキストドキュメントビューア」以外でテキストをレンダリングしたい人なんて、まさかいないとでも思った？信じられないね！
あんたがテキスト関連の仕事をしてないことを、マジで願ってるよ。
まさに「主人公症候群」の典型例だね。文字通りダジャレじゃないよw
信じられないかもしれないけど、あんた以外の人間も存在するんだよ。
ASCII文字だけの等幅フォントならいいけど、それ以外だとすぐ変になっちゃうよ。
すごい技術だけど、サブピクセルAAはもういらないんじゃね？昔72dpiの時代はよかったけど、今のRetinaディスプレイだと違いわかんないし。
ちょっとした改善のために、不透明背景しかダメとか、効果つけられないとか、スクショが他のディスプレイで見ると変とか、デメリット多いし。
サブピクセルAAなくすと楽になるけど、低DPIモニター使ってる人まだ結構いるよ。Firefoxの調査だと16パーセントが1366x768だって。今でも新しい低DPIのモニターやノートPC作られてるしね。
[1] https://data.firefox.com/dashboard/hardware
もっとびっくりするかもだけど、FHD以下使ってる人が全体の3分の2で、QHDとか4Kは6分の1くらいなんだって。デスクトップだと、まだ低DPIが普通ってことみたいだよ。
あと、Linux Hardware Database（開発者寄りね）[1] とSteam Hardware & Software Survey（ゲーマー寄り）[2] も見てみて。
[1] https://linux-hardware.org/?view=mon_resolution
[2] https://store.steampowered.com/hwsurvey
それって『俺、高DPIの画面だから、そうじゃない人のことは知ったこっちゃない』って言ってるようなもんだろ？サブピクセルレンダリングが効く場面での良い結果に比べたら、他の話はマジでどうでもいいレベルだよ。
そうかなあ。俺は100dpiの画面だと色のフリンジが出るのが嫌で、サブピクセルレンダリングあんまり好きじゃないんだよね。他のデメリットも加味したら、やっぱり割に合わない感じ。
サブピクセルレンダリングって設定できるんだよ。特許切れたアルゴリズムもあるし。俺は最新のKubuntuでヒンティングとサブピクセルレンダリング使ってるけど、めっちゃ綺麗に見えるよ。あんま使わないけどWindowsでもClearType Tunerで設定したことあるけど、Windowsのフォントレンダリングは全体的にちょっと粒々してて細い感じなんだよね。
それにさ、もし筆者が望むみたいに、ディスプレイのサブピクセル配置を知るためのプロトコルができて、それが広く使われるようになっても、絶対一部のメーカーが間違えて、ユーザーにはマジで理解不能なレンダリング問題起こすって。間違いないね。
こういう問題は前からあったんだよ。で、解決策もちゃんとわかってる。ハードにプロトコルで聞く、間違った情報返すハードウェア用のquirkデータベース、そしてユーザーが自分で設定を変えられるオーバーライド、これね。
