ハードウェアアクセラレーションによるベクターグラフィックスが機能しないのはなぜですか？
私は60fpsでのベクトルパスのリアルタイム操作を含むアプリを開発していますが、この件に関する情報がほとんどないことに驚いています。最初は、CoreGraphicsを使用して自分のアイデアを実装しようとしましたが、それは 目的に対して適切に実行されませんでした です。その後、ハードウェアアクセラレーションベクターグラフィックスに OpenVG と呼ばれるKhronos標準があることを発見し、ありがたいことに、親切な魂が MonkVG と呼ばれるOpenGL ESの準実装を作成しました。
しかし、OpenVGは非常に実用的なAPIであるという事実にもかかわらず、それは多かれ少なかれKhronosによって見捨てられたようです。ウィキペディアによると、2011年以降、ワーキンググループは「さらなる標準化のために定期的な会議を開かないことを決定しました」としています。ドキュメントは、私が見つけることができる最良のものですが、参照カードが1つだけで構成されています。さらに、インターネット上のOpenVGの例はほとんどありません。何百ものOpenGLチュートリアルを一瞬で見つけることができますが、OpenVGは著しく欠けているようです。
ハードウェアアクセラレーションによるベクターは、解像度が急速に向上している今日の世界ではより重要であると考えているでしょう。たとえば、QtとFlashにはハードウェアアクセラレーションベクターのスキームがあり、アドビのツールの多くにはオプションとしてハードウェアアクセラレーションがあります。しかし、標準がすでに存在する場合、ホイールは再発明されているようです！
OpenVGについて、実世界での使用に適さないようにするために欠けているものはありますか？それとも、規格が間に合わず、今ではあいまいなものになっているのでしょうか？将来、ハードウェアアクセラレーションベクターグラフィックス用の標準化されたAPIの余地はあると思いますか、それとも従来のラスターベースの手法を使用する方が簡単でしょうか？それとも、ベクターが登場する前に、単にベクターが出て行くのでしょうか？
update：返信の下部を参照してください
この答えは少し遅すぎますが、私は他の人に光を当てたいと思います（特に、C++標準委員会がCairoをstdに組み込むことを望んでいる今）。
「アクセラレートされたベクターグラフィックス」について誰も気にしない理由は、GPUのしくみにあります。 GPUは、大規模な並列化とSIMD機能を使用して各ピクセルに色を付けます。 AMDは通常、 64x648x8ピクセル（NVIDIAカードは通常、 32x32 4x4ピクセル[下部の更新を参照]
3Dの三角形をレンダリングしている場合でも、GPUはこの三角形がカバーする四角形全体で機能します。したがって、三角形がブロック内のすべての8x8ピクセル（nvidiaの場合は4x4）をカバーしていない場合、GPUはカバーされていないピクセルの色を計算し、その結果を破棄します。言い換えると、カバーされていないピクセルの処理能力が浪費されます。これは無駄に思えますが、大量の数とペアにすると、3D三角形のレンダリングlargeに非常に役立ちますGPUコアの数（詳細はこちら-- 基本的なラスタライザの最適化 ）。
そのため、ベクターベースのラスタライズを振り返ると、線を描くときに、太くても大量の空白があることに気付くでしょう。大量の処理能力が浪費され、さらに重要なのは帯域幅（これは電力消費の主な原因であり、多くの場合ボトルネックです）したがって、8の倍数の太さの水平線または垂直線を描画している場合を除きおよび8ピクセル境界に完全に位置合わせされているため、多くの処理能力と帯域幅が浪費されます。
レンダリングするハルを計算することで「無駄」の量を減らすことができます（NV_path_renderingのように）が、GPUは8x8/4x4ブロックに制限されています（おそらく、NVIDIAのGPUベンチマークは、より高い解像度、pixels_covered/pixel_wasted比率でより適切にスケーリングされます）はるかに低いです）。
これが、多くの人が「ベクトルハードウェアアクセラレーション」についてさえ気にしない理由です。 GPUは単にこのタスクに適していません。
NV_path_renderingは標準よりも例外であり、ステンシルバッファーを使用するという新しいトリックが導入されています。圧縮をサポートし、帯域幅の使用量を大幅に削減できます。
それにもかかわらず、私はNV_path_renderingに懐疑的であり、少しグーグルで示すことで、OpenGL（別名推奨方法）を使用するときのQtは、NVIDIAのNV_path_renderingよりも大幅に高速です： NVパスレンダリング つまり、NVIDIAのスライドは「誤って」XRenderのQtのバージョンを比較します。おっと。
「ハードウェアアクセラレーションを使用したすべてのベクター描画の方が速い」と主張する代わりに、Qt開発者は、ハードウェアアクセラレーションを使用したベクター描画の方が常に優れているとはより正直に認めています（レンダリングの説明をご覧ください： Qt Graphics and Performance – OpenGL ）
また、オンザフライで三角形のストリップを生成する必要がある「ライブ編集」ベクターグラフィックスの部分には触れていません。複雑なsvgを編集する場合、これは実際に深刻なオーバーヘッドを追加する可能性があります。
それがより良いかどうかにかかわらず、それはアプリケーションに大きく依存します。あなたの元の質問「なぜそれがうまくいかなかったのか」に関して、私はそれが今答えられることを望みます：考慮すべき多くの不利な点と制約があり、多くの人が懐疑的になり、それらを実装しないようにバイアスをかけるかもしれません。
update：前述のGPUは64x64および32x32ブロックではなく8x8ブロックでラスタライズされないため、数値が完全にずれていると指摘されました。 64および4x4 = 16.これは、投稿の結論をかなり無効にします。この記事は後日、最新の情報で更新します。
this answer で記述されているように、「加速ベクターグラフィックス」を誰も気にしていないというのは本当だとは思いません。
Nvidiaはかなり気にかけているようです。 NV_path_rendering（以降、NVprが私の指を救う）の主任技術者であるKilgardの他に、NvidiaのVPでもあるKhronosの社長であるNeil Trevettは、NVprをできるだけ昇進させました過去数年;彼の talk1 、 talk2 または talk を参照してください。そして、それは少しうまくいったようです。この記事を執筆している時点で、Kilgardのスライドによると、NVprはGoogleのSkia（Google Chromeでも使用されています）とAdobe Illustrator CC（ベータ版）のベータ版で独立して使用されています GTC14 ;ここで行われた講演のビデオもいくつかあります： Kilgard's および Adobe's 。 Cairo dev（Intelで動作）も 興味があるようです NVprで。 Mozilla/Firefoxの開発者もNVprを試してみましたが、実際には次のように、GPUアクセラレートされたベクターグラフィックスを一般的に考慮しています FOSDEM14 トーク。
MicrosoftはDirect2Dを作成したので、かなり気にしています。これはかなり広く使われています（前述の講演でMozillaの開発者と思われる場合）。
ここで、元の質問の要点に到達します。実際に、パスのレンダリングにGPUを使用することが簡単ではない技術的な理由がいくつかあります。パスレンダリングがバグ標準の3D頂点ジオメトリとどのように異なるか、およびパスレンダリングのGPUアクセラレーションが重要な理由について読みたい場合は、 KilgardはFAQのような非常に優れた投稿を提供しています 、これは残念ですOpenGLフォーラムのどこかに埋められました。
Direct2D、NVprなどの機能の詳細については、 KilgardのSiggraph 2012論文 を参照してください。これはもちろんNVprに焦点を当てていますが、以前のアプローチの調査にも適しています。クイックハッキングはあまりうまく機能しないと言えば十分です...（PSEの質問のテキストが指摘しているように）。この論文で説明され、Kilgardの初期のデモの一部で示されているように、これらのアプローチにはパフォーマンスの大きな違いがあります。 このビデオ 。 公式のNVpr拡張ドキュメント には、長年にわたるいくつかのパフォーマンスチューニングの詳細も記載されています。
（最初にリリースされた実装で）2011年にLinuxでNVprがそれほど優れていなかったからといって、QtのZack Rusinの 2011ブログ投稿 が言ったように、GPUによるベクトル/パスの高速化は意味しませんゴールドバーグ氏の答えがそれから推測したように見えるので、絶望的です。 Kilgardは実際には 更新されたドライバーでそのブログ投稿の最後に返信されました Qtのより高速なコードに比べて2倍から4倍の改善を示し、Rusinはその後何も述べていません。
Valve Corp.は、GPUアクセラレーションによるベクターレンダリングにも注意を払っていますが、フォント/グリフレンダリングに関連して、より限定的な方法で行っています。彼らは、GPU加速署名距離フィールド（SDF） Siggraph 2007で発表 を使用した、大きなフォントスムージングのすばやい実装を高速で実現しています。これは、TFなどのゲームで使用されています。 テクニックのビデオデモ がYouTubeに投稿されています（ただし、誰が作成したかはわかりません）。
SDFアプローチでは、カイロとパンゴの開発者の1人がGLyphyの形式でいくつかの改良を加えています。その著者は linux.conf.au 2014での講演 を与えました。あまりにも長く見ていなかったバージョンは、SDF計算を（ラスターではなく）ベクトル空間で扱いやすくするために、ベジェ曲線のアークスプライン近似を実行している（Valveが後者を実行した）。しかし、円弧スプライン近似を使用しても、計算は依然として低速でした。彼の最初のバージョンは3 fpsで動作したと彼は言った。そのため、彼は「距離が離れすぎている」ものに対してグリッドベースのカリングを実行します。これは、LOD（詳細レベル））の形式に似ていますが、SDF空間で行われます。この最適化により、彼のデモが実行されました60 fps（そしておそらくVsyncの制限があった）。しかし彼のシェーダーは信じられないほど複雑であり、ハードウェアとドライバーの限界を押し広げている。彼は次のように言った：「すべてのドライバー/ OSの組み合わせについて、私たちは物事を変えなければなりませんでした。」また、シェーダーコンパイラーに重大なバグが見つかり、その一部はそれぞれの開発者によって修正されたため、AAAゲームタイトルの開発によく似ています...
別の取り組みとして、Microsoftは Windows 8で使用されているハードウェア を使用してDirect2D実装を改善するために、新しいGPUハードウェアを少し依頼/指定したようです。これはターゲットに依存しないラスター化（[〜＃〜] tir [〜＃〜]）と呼ばれ、何について少し誤解を招く名前です。実際にそうであるように書かれています Microsoftの特許出願中 。 AMDは次のように主張しています TIRは2Dベクトルグラフィックスのパフォーマンスを約500％改善しました 。そして、AMDのGCNベースのGPUが持っているのに対して、Kepler GPUにはないので、それらとNvidiaの間には少し "war of words" がありました。 Nvidiaが確認しました これは確かに新しいハードウェアのほんの少しであり、単にドライバの更新で提供できるものではありません。 Sinofskyのブログ投稿 には、TIRの実際のベンチマークを含む、いくつかの詳細があります。私は一般的なアイデアのビットのみを引用しています：
不規則なジオメトリ（地図上の地理的な境界など）をレンダリングするときのパフォーマンスを向上させるために、Target Independent Rasterization（TIR）と呼ばれる新しいグラフィックハードウェア機能を使用します。
TIRを使用すると、Direct2Dがテセレーションに費やすCPUサイクルが少なくなるため、視覚的な品質を犠牲にすることなく、GPUに描画命令をより迅速かつ効率的に提供できます。 TIRは、DirectX 11.1をサポートするWindows 8用に設計された新しいGPUハードウェアで利用できます。
以下は、TIRをサポートするDirectX 11.1 GPUでさまざまなSVGファイルからアンチエイリアスされたジオメトリをレンダリングするパフォーマンスの改善を示すグラフです：[chart snipped]
グラフィックハードウェアパートナー[AMDを読む]と緊密に協力してTIRを設計しました。そのパートナーシップのおかげで劇的な改善が可能になりました。 DirectX 11.1ハードウェアはすでに市場に出回っており、パートナーと協力して、より多くのTIR対応製品が広く利用できるようにしています。
これは、Win 8が追加した素敵な機能の1つで、Metro UIの大失敗で世界にほとんど失われていたと思います...
おそらく、そのメリットがコストを上回らないためです。