No creo que sea realmente cierto que a nadie realmente le importen los "gráficos vectoriales acelerados" tal como están escritos en esta respuesta .
A Nvidia parece importarle un poco. Además de Kilgard, que es el técnico principal en NV_path_rendering (en adelante NVpr para salvar mis dedos), el presidente de Khronos, Neil Trevett, quien también es vicepresidente de Nvidia, ha promovido NVpr tanto como pudo en los últimos años; ver su talk1 , talk2 o talk3 . Y eso parece haber valido la pena un poco. Al momento de escribir esto, NVpr ahora se usa en Skia de Google (que a su vez se usa en Google Chrome) y de forma independiente [de Skia] en una versión beta de Adobe Illustrator CC (beta), según las diapositivas de Kilgard en GTC14 ; También hay algunos videos de las charlas ofrecidas allí: Kilgard y Adobe. Un desarrollador de Cairo (que trabaja para Intel) también parece interesado en NVpr. Los desarrolladores de Mozilla / Firefox también experimentaron con NVpr y, de hecho, se preocupan por los gráficos vectoriales acelerados por GPU en general, como muestra esta charla FOSDEM14 .
A Microsoft también le importa un poco porque crearon Direct2D , que se usa bastante ampliamente [si cree en el desarrollador de Mozilla de la charla antes mencionada].
Ahora, para llegar al punto de la pregunta original: de hecho, hay algunas razones técnicas por las que el uso de GPU para la representación de rutas no es sencillo. Si desea leer acerca de cómo la representación de ruta difiere de la geometría de vértice 3D estándar de pantano y qué hace que la aceleración de GPU de la representación de ruta no sea trivial, entonces Kilgard tiene una muy buena publicación de preguntas frecuentes , que desafortunadamente está enterrada en algún lugar del foro OpenGL.
Para obtener más detalles sobre cómo Direct2D, NVpr y ese tipo de trabajo, puede leer el documento Siggraph 2012 de Kilgard , que, por supuesto, se centra en NVpr, pero también hace un buen trabajo al examinar enfoques anteriores. Baste decir que los hacks rápidos no funcionan demasiado bien ... (como se señala en el texto de la pregunta del PSE). Existen diferencias de rendimiento significativas entre estos enfoques, tal como se discutió en ese documento y se mostró en algunas de las primeras demostraciones de Kilgard, por ejemplo, en este video . También debo tener en cuenta que el documento oficial de extensión NVpr detalla varios ajustes de rendimiento a lo largo de los años.
El hecho de que NVpr no fuera tan bueno en Linux en 2011 (en su primera implementación lanzada), como dijo esa publicación de blog de 2011 de Qt's Zack Rusin, no significa que la aceleración de vectores / rutas de GPU sea inútil como la respuesta del Sr. Goldberg parece haber inferido de eso. De hecho, Kilgard respondió al final de esa publicación de blog con controladores actualizados que muestran una mejora de 2x-4x sobre el código más rápido de Qt y Rusin no ha dicho nada después de eso.
Valve Corp. también se preocupa por la representación vectorial acelerada por GPU, pero de manera más limitada, en relación con la representación de fuente / glifo. Han tenido una implementación agradable y rápida de suavizado de fuentes grandes utilizando campos de distancia con signo acelerados por GPU (SDF) presentados en Siggraph 2007 , que se utiliza en sus juegos como TF; Hay una demostración en video de la técnica publicada en YouTube (pero no estoy seguro de quién lo hizo).
El enfoque SDF ha visto algunos refinamientos por parte de uno de los desarrolladores de El Cairo y pango en forma de GLyphy ; su autor dio una charla en linux.conf.au 2014. La versión demasiado larga no observada es que hace una aproximación de arco-spline de las curvas de Bezier para hacer que el cálculo de SDF sea más manejable en el espacio vectorial (en lugar de en la trama) (Valve hizo lo último). Pero incluso con la aproximación de arco-spline, el cálculo seguía siendo lento; Dijo que su primera versión corrió a 3 fps. Así que ahora hace algunos sacrificios basados en la cuadrícula para cosas que están "demasiado lejos", lo que parece una forma de LOD (nivel de detalle) pero en el espacio SDF. Con esta optimización, sus demos corrieron a 60 fps (y probablemente era Vsync limitado). Sin embargo, sus sombreadores son increíblemente complejos y superan los límites del hardware y los controladores. Dijo algo como: "para cada combinación de controlador / sistema operativo tuvimos que cambiar las cosas". También encontró errores significativos en los compiladores de sombreadores, algunos de los cuales fueron arreglados por sus respectivos desarrolladores. Así que se parece mucho al desarrollo de títulos de juegos AAA ...
En otra táctica, parece que Microsoft ha encargado / especificado un poco de nuevo hardware de GPU para mejorar su implementación de Direct2D, hardware que utiliza Windows 8, si está disponible . Esto se llama rasterización independiente del objetivo ( TIR ), un nombre que es un poco engañoso en cuanto a lo que realmente parece hacer, que se explica en la solicitud de patente de Microsoft . AMD afirmó que TIR mejoró el rendimiento en gráficos vectoriales 2D en un 500% . Y hubo un poco de "guerra de palabras" entre ellos y Nvidia porque las GPU Kepler no lo tienen, mientras que las GPU basadas en GCN de AMD sí. Nvidia ha confirmadoque esto es de hecho un poco de hardware nuevo, no simplemente algo que puede proporcionar una actualización de controlador. La publicación del blog de Sinofsky tiene algunos detalles más, incluidos algunos puntos de referencia reales de TIR. Cito solo los bits de idea general:
Para mejorar el rendimiento al representar geometrías irregulares (p. ej., bordes geográficos en un mapa), utilizamos una nueva característica de hardware de gráficos llamada Target Rasterization independiente o TIR.
TIR permite que Direct2D gaste menos ciclos de CPU en la teselación, por lo que puede dar instrucciones de dibujo a la GPU de manera más rápida y eficiente, sin sacrificar la calidad visual. TIR está disponible en el nuevo hardware de GPU diseñado para Windows 8 que admite DirectX 11.1.
A continuación se muestra un gráfico que muestra la mejora del rendimiento para renderizar geometría suavizada de una variedad de archivos SVG en una GPU DirectX 11.1 compatible con TIR: [gráfico recortado]
Trabajamos estrechamente con nuestros socios de hardware de gráficos [lea AMD] para diseñar TIR. Dramáticas mejoras fueron posibles gracias a esa asociación. El hardware DirectX 11.1 ya está en el mercado hoy y estamos trabajando con nuestros socios para asegurarnos de que haya más productos con capacidad TIR disponibles.
Supongo que esta fue una de las cosas buenas que agregó Win 8 que se perdió principalmente en el mundo en el fiasco de la interfaz de usuario de Metro ...