Je ne pense pas qu'il soit vraiment vrai que personne ne se soucie vraiment des "graphiques vectoriels accélérés" tels qu'ils sont écrits dans cette réponse .
Nvidia semble se soucier un peu. Outre Kilgard, qui est le responsable technique principal de NV_path_rendering (désormais NVpr pour sauver mes doigts), le président de Khronos, Neil Trevett, également vice-président de Nvidia, a promu NVpr autant que possible ces dernières années. voir son talk1 , talk2 ou talk3 . Et cela semble avoir payé un peu. Au moment de la rédaction de cet article, NVpr est maintenant utilisé dans Google Skia (qui à son tour est utilisé dans Google Chrome) et indépendamment [de Skia] dans une version bêta d’Adobe Illustrator CC (version bêta), selon les diapositives de Kilgard à la CG14 ; il y a aussi quelques vidéos des conférences données ici: Kilgard et Adobe. Un développeur du Caire (qui travaille pour Intel) semble également intéressé par NVpr. Les développeurs Mozilla / Firefox ont également expérimenté NVpr. Ils s’intéressent en fait au graphisme vectoriel accéléré par GPU en général, comme le montre ce talk FOSDEM14 .
Microsoft s’intéresse également beaucoup au fait qu’ils ont créé Direct2D , qui est utilisé assez largement [si vous croyez que la version de Mozilla est tirée du discours susmentionné].
Passons maintenant à la question initiale: il existe en effet des raisons techniques pour lesquelles l’utilisation de GPU pour le rendu de chemin n’est pas simple. Si vous voulez savoir en quoi le rendu de chemin diffère de la géométrie de sommet 3D standard et ce qui rend l'accélération GPU du rendu de chemin non triviale, alors Kilgard a un très bon article de type FAQ , malheureusement enfoui quelque part sur le forum OpenGL.
Pour plus de détails sur la façon dont Direct2D, NVpr et ce type de travail, vous pouvez lire le document de Kilgard Siggraph 2012 , qui est bien sûr axé sur NVpr, mais qui fait également un bon travail en examinant les approches antérieures. Il suffit de dire que les piratages rapides ne fonctionnent pas très bien ... (comme le souligne le texte de la question sur les PSE). Il existe des différences de performances significatives entre ces approches décrites dans ce document et montrées dans certaines des premières démos de Kilgard, par exemple dans cette vidéo . Je dois également noter que le document d'extension NVpr officiel détaille plusieurs réglages de performances effectués au cours des années.
Ce n'est pas parce que NVpr n'était pas si performant sous Linux en 2011 (dans sa première mise en service publiée), comme le disait dans l'article de Zt Rusin de Qt en 2011 , que l'accélération GPU des vecteurs / chemins est sans espoir, a répondu M. Goldberg. semble avoir déduit de cela. Kilgard a en fait répondu à la fin de ce billet de blog avec des pilotes mis à jour montrant une amélioration 2x-4x par rapport au code plus rapide de Qt et Rusin n'a rien dit par la suite.
Valve Corp. s'intéresse également au rendu vectoriel accéléré par le GPU, mais de manière plus limitée, en ce qui concerne le rendu des polices / glyphes. Ils ont eu une bonne et rapide implémentation du lissage des grosses polices avec les champs de distance signés (SDF) accélérés par le GPU présentés à Siggraph 2007 , qui sont utilisés dans leurs jeux comme TF; il y a une démonstration vidéo de la technique publiée sur YouTube (mais je ne sais pas qui a fait ça).
L’approche SDF a vu certains des perfectionnements apportés par l’un des développeurs du Caire & pango sous la forme de GLyphy ; son auteur a donné une conférence à linux.conf.au 2014. La version trop longue-regardée est qu’il effectue une approximation arc-spline des courbes de Bézier afin de rendre le calcul SDF plus facile à manipuler dans l’espace vectoriel (plutôt que dans l’affichage raster) (ce dernier est fait par Valve). Mais même avec l'approximation arc-spline, le calcul était toujours lent; il a dit que sa première version a fonctionné à 3 fps. Donc, il effectue maintenant une sélection basée sur la grille pour des éléments "trop éloignés", qui ressemblent à une forme de LOD (niveau de détail) mais dans l'espace SDF. Avec cette optimisation, ses démos ont fonctionné à 60 fps (et il était probablement limité à Vsync). Cependant, ses shaders sont incroyablement complexes et repoussent les limites du matériel et des pilotes. Il a dit quelque chose du genre: "pour chaque combinaison pilote / système d'exploitation, nous devions changer les choses". Il a également trouvé des bugs importants dans les compilateurs de shader, certains d'entre eux ont ensuite été fixés par leurs développeurs respectifs. Cela ressemble donc beaucoup au développement de titres de jeux AAA ...
Sur un autre plan, il semble que Microsoft ait commandé / spécifié un peu de nouveau matériel de processeur graphique afin d’améliorer leur implémentation de Direct2D avec le matériel utilisé par Windows 8, le cas échéant . C'est ce qu'on appelle la rastérisation TIR ( Target-Independent Rasterization ), nom trompeur quant à ce que semble réellement faire le travail, qui est décrit dans la demande de brevet de Microsoft . AMD a affirmé que le TIR améliorait les performances graphiques vectorielles 2D de 500% environ . Et il y avait un peu de "guerre des mots" entre eux et Nvidia parce que les GPU Kepler ne l'ont pas, contrairement aux GPU d'AMD basés sur GCN. Nvidia a confirméqu’il s’agit bien d’un nouveau matériel, et pas simplement d’une mise à jour de pilote. Le blog de Sinofsky contient quelques détails supplémentaires, y compris quelques points de repère réels du TIR. Je ne cite que les idées générales:
Pour améliorer les performances lors du rendu d'une géométrie irrégulière (par exemple, des bordures géographiques sur une carte), nous utilisons une nouvelle fonctionnalité matérielle graphique appelée Rasterisation Indépendante, ou TIR.
TIR permet à Direct2D de passer moins de cycles de processeur sur la tessellation, ce qui lui permet de donner des instructions de dessin au GPU plus rapidement et plus efficacement, sans sacrifier la qualité visuelle. TIR est disponible dans le nouveau matériel GPU conçu pour Windows 8 et prenant en charge DirectX 11.1.
Vous trouverez ci-dessous un graphique illustrant l'amélioration des performances de rendu de la géométrie anti-aliasée à partir de divers fichiers SVG sur un processeur graphique DirectX 11.1 prenant en charge le format TIR: [chart snipped]
Nous avons travaillé en étroite collaboration avec nos partenaires de matériel graphique [lire AMD] pour concevoir le TIR. Des améliorations spectaculaires ont été rendues possibles grâce à ce partenariat. Le matériel DirectX 11.1 est déjà sur le marché aujourd'hui et nous travaillons avec nos partenaires pour nous assurer que davantage de produits compatibles TIR seront largement disponibles.
Je suppose que Win 8 a ajouté que c’était une des bonnes choses qui avait été perdue pour la plupart dans le fiasco de l’interface utilisateur de Metro ...