Discussion :

[electroremy]

Bonjour,

j'ai conçu un logiciel de dessin CAO/ d'affichage de graphismes sous VB5, puis sous VB.NET.

Mais GDI et GDI+ c'est lent, donc je souhaite essayer de créer une appli WPF avec Visual Basic 2010.

Je viens d'y passer deux jours, et entre les DrawingContext, DrawingVisual, BitmapSource, CachedBitmap... je ne m'y retrouve pas Je n'arrive même pas à afficher une ligne dans mon contrôle image.

Avez-vous un bon tutoriel là dessus ? J'ai trouvé pas mal de trucs en anglais et c'est assez opaque...

Merci

[electroremy]

Bonsoir,

Finalement je suis arrivé à mes fins.

J'ai fait 4 versions différentes du même un petit programme qui fait de l'affichage 3D maison, avec 4 versions de VB différentes, pour comparer les performances.

Voici un aperçu du programme :



Voici les résultats (temps moyen pour afficher la scène) :
- VB.NET 2010 : 142ms
- VB5 avec API Polygon : 197ms
- VB5 : 311ms
- WPF VB 2010 : 361ms - de plus l'application est lente à quitter

Tous les codes sources et les exécutables sont téléchargeables ici : http://electroremy.free.fr/3D/3D2D_TEST.zip

Je suis déçu de ce que j'ai obtenu avec WPF mais il est très probable que je n'utilise pas la bonne méthode avec ce langage.

Comment faire pour avoir des fonctions graphiques rapides avec WPF ? Y compris lorsque mon code doit pouvoir continuer à agir sur les éléments dessinés (par exemple changer la couleur d'une ligne).

Je me demande aussi si WPF est performant seulement quand c'est lui qui gère le dessin et pas au moment où on créé le dessin à partir du code; dans ce cas de figure, il serait intéressant d'utiliser WPF dans des applis où on charge un modèle et ensuite on le déplace à la souris, mais pas pour dessin type CAO ?

A bientôt

[DonQuiche]

Tu utilises mal WPF (et peut-être les autres) et tu as une mauvaise perception de ce qu'est une carte graphique.

Donc une carte graphique n'est pas un périphérique magique capable d'accélérer de petites opérations de rendu. Au contraire c'est une gros accélérateur situé très loin du CPU, entre lesquels il y a un bus avec une latence de plusieurs microsecondes, et ayant sa propre mémoire. On y stocke les primitives une fois pour toutes en essayant de ne jamais les lire ou les modifier, et on lui envoie aussi peu de commandes de rendu que possible ("batch, batch, batch" - on groupe les primitives ayant les mêmes shaders et textures en un seul gros maillage de milliers ou centaines de milliers de triangles).

Pour ces raisons WPF est optimisé pour un mode "retained" (gestion d'une scène) : à chaque fois que tu crées une primitive de dessin celui-ci doit générer le maillage et le shader qui seront utilisés par la carte graphique puis tenter de batcher dynamiquement, de l'insérer son graphe de rendu, etc. Par ailleurs WPF expose des objets de haut-niveau capables de supporter des événements, de détecter des clics, etc.


En résumé : on crée les primitives une seule fois, on ne les change que lorsqu'il le faut, on crée aussi peu de primitives que possibles, et on laisse WPF se débrouiller autant que possible.

Cela dit ça ne doit pas être le seul problème pour obtenir 361ms de latence. TU n'aurais pas inclus un temps de démarrage ou fait autre chose de très lent ?

[electroremy]

Tu utilises mal WPF (et peut-être les autres) et tu as une mauvaise perception de ce qu'est une carte graphique.

Donc une carte graphique n'est pas un périphérique magique capable d'accélérer de petites opérations de rendu. Au contraire c'est une gros accélérateur situé très loin du CPU, entre lesquels il y a un bus avec une latence de plusieurs microsecondes, et ayant sa propre mémoire. On y stocke les primitives une fois pour toutes en essayant de ne jamais les lire ou les modifier, et on lui envoie aussi peu de commandes de rendu que possible ("batch, batch, batch" - on groupe les primitives ayant les mêmes shaders et textures en un seul gros maillage de milliers ou centaines de milliers de triangles).

Pour ces raisons WPF est optimisé pour un mode déféré : à chaque fois que tu crées une primitive de dessin celui-ci doit générer le maillage et le shader qui seront utilisés par la carte graphique puis tenter de batcher dynamiquement, de l'insérer son graphe de rendu, etc. Par ailleurs WPF expose des objets de haut-niveau capables de supporter des événements, de détecter des clics, etc.


En résumé : on crée les primitives une seule fois, on ne les change que lorsqu'il le faut, on crée aussi peu de primitives que possibles, et on laisse WPF se débrouiller autant que possible.

Cela dit ça ne doit pas être le seul problème pour obtenir 361ms de latence. TU n'aurais pas inclus un temps de démarrage ou fait autre chose de très lent ?

C'est exactement ça Tu as parfaitement compris ce que je ne comprends pas

Il faut que je coupe mon code en deux, une partie gérée par le CPU, et une par le GPU

La difficulté est de minimiser les échanges de données entre les deux parties... il faut surtout éviter, pour chaque affichage, de récréer entièrement les données dans le GPU à partir du code géré par le CPU (c'est ce que je fais actuellement)

Cela suppose, par exemple, de pouvoir modifier la couleur d'un élément dans le dessin stocké dans le GPU depuis le CPU, sans tout recréer. De même, pour faire des ajouts et suppressions d’éléments sans tout récréer.

Est-il possible d'avoir cette approche aussi en VB5 ou en VB.NET ? ou est-ce réservé au WPF ?

Par contre je ne sais pas du tout comment m'y prendre

Avez-vous un bon tuto ou un bon livre à me conseiller à ce sujet ? Si possible en français ou sinon en anglais ?

Merci, A+

[DonQuiche]

Il faut que je coupe mon code en deux, une partie gérée par le CPU, et une par le GPU

Il faut que tu sépares la création des primitives (écriture des données géométriques en coordonnées monde) de leur rendu (projection, coloriage et dessin). Dans le cas de WPF tu n'as en fait pas à t'occuper du rendu, le Viewport3D le fera à ta place en fonction des couples géométrie / matériaux fournis.

Cela suppose, par exemple, de pouvoir modifier la couleur d'un élément dans le dessin stocké dans le GPU depuis le CPU, sans tout recréer. De même, pour faire des ajouts et suppressions d’éléments sans tout récréer.

Qu'appelles-tu un élément et quel genre de changement veux-tu faire ?
S'il s'agit de modifier la couleur d'une seule face WPF devra renvoyer les données mais ce n'est pas grave. En revanche tu devras de ton côté seulement modifier une face en général, pas recréer tout un modèle.

Est-il possible d'avoir cette approche aussi en VB5 ou en VB.NET ? ou est-ce réservé au WPF ?

L'API GDI+ sur laquelle repose le dessin en WinForms et compagnie fonctionne uniquement en mode immédiat (on redessine tout à chaque fois).
Mais tu peux toujours utiliser une API 3D ou mettre en cache certaines parties de l'image.

Avez-vous un bon tuto ou un bon livre à me conseiller à ce sujet ? Si possible en français ou sinon en anglais ?

Non mais cherche "WPF Viewport3D" et "ModelUIElement3D".
Cela dit je ne vais pas pouvoir t'aider bien longtemps, je connais peu le rendu 3D en WPF.

[electroremy]

Qu'appelles-tu un élément et quel genre de changement veux-tu faire ?
S'il s'agit de modifier la couleur d'une seule face WPF devra renvoyer les données mais ce n'est pas grave. En revanche tu devras de ton côté seulement modifier une face en général, pas recréer tout un modèle.

Dans ma structure de données, je vais avoir une liste de parcours d'outils, chaque parcours correspond :
- à une ligne du programme CN à examiner
- à quelque chose à afficher à l'écran

Mon programme va permettre à l'utilisateur de choisir, suivant certains critères, les parcours à afficher ou pas, et avec des couleurs différentes selon que le parcours est un déplacement rapide hors de la pièce ou un déplacement dans la pièce qui usine, ou selon d'autres critères (numéro de l'outil utilisé, sens de la broche, ect...). Le but est que l'utilisateur puisse "explorer" visuellement le programme CN en distinguant certains catégories de parcours les unes des autres pour vérifier que le programme CN réalise bien les opérations demandées.

Depuis l'interface utilisateur, l'utilisateur va pouvoir cliquer sur des cases à cocher qui vont avoir pour effet de cacher ou de montrer les parcours, et/ou de changer leur couleur.

Je pense stoker dans le Viewport3D l'ensemble des parcours, calculés une bonne fois pour toute à la lecture du fichier CN, et ensuite depuis le code pouvoir changer les propriétés des parcours. Le Viewport3D gérera l'affichage, notamment quand l'utilisateur change l'angle de vue ou le zoom.

J'espère que c'est suffisamment clair pour toi

L'API GDI+ sur laquelle repose le dessin en WinForms et compagnie fonctionne uniquement en mode immédiat (on redessine tout à chaque fois).
Mais tu peux toujours utiliser une API 3D ou mettre en cache certaines parties de l'image.

OK - Donc pour VB5 ou .NET, passage par DirectX ou autre.

Non mais cherche "WPF Viewport3D" et "ModelUIElement3D".

OK merci, je vais voir de quoi ça parle

Cela dit je ne vais pas pouvoir t'aider bien longtemps, je connais peu le rendu 3D en WPF.

J'ai aussi des programmes qui ne font que de la 2D que je souhaiterais faire en WPF, pour cela, quoi me conseilles tu ?

A+ et merci encore pour tes réponses