WPF or not WPF ?

Version imprimable

09/02/2015, 10h53
electroremy

WPF or not WPF ?

Bonjour à tous,

Je souhaite développer une petite application qui va lire un fichier GCODE (cela correspond à des commandes envoyées à une fraiseuse numérique) et ensuite faire diverses vérifications, dont le traçage en 3D ou en 2D des parcours outils. Le traçage sera en fil de fer. Cette application va servir à vérifier que d'autres applications font correctement leur job, pour éviter d'avoir à usiner X objets avec une machine réelle pour leur déboggage :mrgreen:

Après quelques recherches j'ai vu que le WPF par rapport au VB traditionnel permettait l'accélération matériel. C'est intéressant

Mais je suis tombé sur un article disant que le WPF serait abandonné et remplacé par le RT

Autre soucis : mon programme va dessiner à partir du code ; autrement dit, ce ne sera pas une scène 3D "extérieure" chargée dans la carte graphique mais les élements du dessins doivent être modifiés ou redessinés à partir du code (genre avec la souris ou le clavier je parcours le listing GCODE et le parcours outil correspondant à la ligne en cours apparaît en rouge, le reste en noir)

Or avec ce principe, est-ce que je vais vraiment profiter de l'accélération matérielle ?

Bref je suis perdu... je continuer à maintenir une grosse appli en VB5, et je développe mes nouvelles applis en VB Express 2010 (qui à priori ne posera pas de problème de compatibilité avec VB 2013). Coder une appli graphique avec l'accélération matérielle m'intéresse beaucoup mais vu que le programme va vivre plusieurs années je souhaite éviter un langage qui va être abandonné.

Autre question : avec VB5 j'ai du .exe qui tourne de windows 95 jusqu'à windows 8. Avec VB.NET ça marche de windows XP jusqu'à windows 8. Qu'en est-il du WPF ?

Autre piste aussi : continuer sous VB.NET mais pour l'affichage faire appel à une système ou API tiers (comme Open GL) mais vu le principe de mon programme ce sera peut être pas intéressant

Merci pour vos éclaircissement ;)
09/02/2015, 11h12
Franck.H

:salut:

Pour moi, qu'on m'arrête si je me trompe, WPF n'est rien d'autre qu'une bibliothèque permettant le rendu vectoriel de la fenêtre et de son contenu. La personnalisation des contrôles en est également plus aisée via XAML mais ça s'arrête là. VB.Net reste du VB.Net, que tu utilises des WPF ou des WinForm classiques. Après le rendu de tes objets (traits, graphiques ou d'autres choses) ne dépendra essentiellement que de ton algorithme et rien d'autre.
09/02/2015, 11h29
Kropernic

Quelques éléments de réponse ici ;-)
09/02/2015, 11h35
Pol63

wpf n'est pas mort, RT par contre oui (ta source devait dater de la sortie de windows RT qui lui vient d'être enterré)

wpf a histoire compliquée, parti d'une bonne idée, il a été différencié par silverlight, silverlight pour windows phone et windows rt, les 4 ont la même syntaxe (le xaml) mais des différences
je pense qu'avec win10 wpf va se recentrer un peu (enfin les dérivés vont surement être abandonnés)

sinon wpf comme windows forms s'appuie sur .net pour le langage de développement, l'interface quand à elle est totalement différente

windows forms s'appuis sur gdi et gdi+ (comme vb5 surement) sans 3d native et sans accélation matérielle (et avec de la transparence bricolée)
wpf permet par contre une totale libertée sur les controles, il permet aussi de la 3d (pas seulement des boutons, on peut réellement faire de la 3d, pas au niveau d'un jeux vidéo complexe par contre)
wpf utilise directX pour le rendu, et est vectoriel ; côté compatibilité windows, ca dépend du framework que tu utilises, wpf existe depuis le fx 3.5, qui est compatible à partir d'xp, le fx 4 ca doit être xp sp3 et le 4.5 ca doit vista sp? (à vérifier sur google)
ca doit rester un gros morceau à appréhender, ca n'a rien à voir avec windows forms et il y a énormément de classes à connaitre, surtout pour faire du dessin

pour faire du wpf il est conseillé d'avoir un visual studio récent (genre 2013) car à la différence de windows forms qui n'a pas beaucoup évolué (et donc était finalisé tôt dans .net) wpf a pas mal évolué et il y avait quelques défauts dans visual studio sur les 1ères versions (intellisense ...)
la version de vs n'est pas liée avec la version du framework utilisée

sinon tu peux passer par directX mais ca doit être encore plus complexe à appréhender

une dernière chose, déjà de passer de vb5 à vb.net c'est un gros morceau, la POO ca ne s'improvise pas, et on aurait tendance à coder de la même manière (à savoir des longs paté de code alors qu'en .net quand on doit écrire 4 lignes de code c'est qu'il y a déjà une méthode qui fait ca ^^)
09/02/2015, 12h55
DonQuiche

Bonjour.

Citation:

Envoyé par electroremy

Mais je suis tombé sur un article disant que le WPF serait abandonné et remplacé par le RT

Pas du tout, tu as dû lire une prophétie datée et loupée. WPF est aujourd'hui la voie principale pour le développement d'applications Windows desktop, point barre. Les API Windows Store/Modern UI/Win RT (MS a un gros problème de nommage) n'ont d'intérêt que pour les applis Windows Store qui pour l'instant ont très peu de succès et la techno n'intéresse pas ou peu les entreprises. Cela pourrait changer avec W10 mais pas à l'heure actuelle.

Les deux grandes alternatives pour le développement Windows moderne sont :
* Javascript pour du dev multiplateforme (mobiles + desktop). Mais ça ne vas pas sans poser de problèmes.
* C++ et Qt pour du dév multiplateformes. Mais c'est moins puissant et plus fastidieux que WPF.

Il y a bien sûr des cohortes d'autres solutions mais rien qui me semble devoir être signalé.

Citation:

Or avec ce principe, est-ce que je vais vraiment profiter de l'accélération matérielle ?

a) La 3D sous WPF est de toute façon inefficace. Simple mais inefficace.

b) En même temps tu n'as pas forcément de gros besoins en performances.

c) Quoi qu'il en soit si tu as besoin de 3D haute performance ça passera par une solution dédiée, souvent maison. Et ce genre de solutions est faisable dans n'importe quelle techno UI (avec sans doute un avantage pour Qt et JS).

d) Ta vision d'une scène résidant dans la mémoire de la CG est erronée : que ce soit un jeu ou une appli de CAO c'est toujours l'appli qui envoie des ordres de rendu à chaque rafraîchissement ("dessine tel maillage avec tel shader dans telle texture/buffer en réglant le z-test/alpha test/backface test comme ceci"). En revanche tu as des API haut niveau comme WPF qui exposent une API permettant de décrire une scène mais le fait que tes maillages soient créées par ton appli ne rend pas du tout l'approche inadaptée, en fait c'est sans doute plus avantageux pour toi car plus simple. Dans les deux cas le problème est de toute façon le même : séparer ta soupe de triangles en différents groupes selon leur apparence (le shader, les textures, etc) et l'ordre de rendu (la transparence impose de trier les objets pour dessiner de l'arrière vers l'avant) ou les paramètres de rendu (z-test & co). AU moins une API de type "scène" prend en général en charge certains aspects comme le tri des objets transparents. Je ne sais pas ce que fait WPF à ce sujet.

Citation:

Envoyé par Pol63

wpf n'est pas mort, RT par contre oui

Vous ne parlez pas du même RT. Toi tu parles de Windows-sur-ARM. Lui parle des API Windows Store.
09/02/2015, 13h15
electroremy

RE

Merci pour vos réponses :)

Citation:

Envoyé par Pol63

une dernière chose, déjà de passer de vb5 à vb.net c'est un gros morceau, la POO ca ne s'improvise pas, et on aurait tendance à coder de la même manière (à savoir des longs paté de code alors qu'en .net quand on doit écrire 4 lignes de code c'est qu'il y a déjà une méthode qui fait ca ^^)

Je vois lis souvent ce genre de commentaire au sujet de la révolution qu'à apporté .NET (et aussi .WPF)

De deux choses l'une : ou je suis blasé, ou je n'ai rien compris, car je ne voit pas d’énorme différence entre VB5 et .NET :mouarf: :oops:

En VB5 j'utilisais déjà beaucoup les classes et les collections. J'ai commencé sur GFA Basic et VB3 il y a très longtemps. Ensuite à l'école j'ai vraiment appris la programmation, on nous a fait bosser la théorie UML, puis sur C++, et enfin un peu sur Java et sur VB5, en insistant beaucoup sur la POO.

J'ai ensuite développé sur VB5 car les IHM de mes programmes étaient complexes. Mais je l'ai fait à la façon POO qu'on m'avait appris. Les vieux langages comme VB3 ne me conviennent plus du tout.

Même avec VBA pour Excel je fais des classes (j'utilise beaucoup excel dans mon boulot)

Avec VB.NET la POO a été poussée jusqu'au bout, tout est objet, pour certaines choses très simple ça peu être limite chiant mais on s'y fait vite; par contre le fait que la logique objet soit respectée jusqu'au bout avec .NET, c'est clairement mieux. Avec VB5 certaines choses coinçait si on abusait trop de la logique objet (j'ai eu un soucis avec une collection que je passait en paramètre dans une fonction par référence, et quand dans la fonction je retirait un élément de la collection il n'était pas retiré de la collection originale)

En fait ça fait des années que je suis déçu par les performances médiocres graphiques de VB5, et aussi de VB.NET. Ces langages permettent de faire des IHM à la fois faciles et parfaitement compatibles avec de nombreuses version de windows, mais au niveau des performances ça craint

Pour du traitement de données lourd (images, ect...) avec des fonctions et certains types de données de VB.NET (comme UInt32, cruellement absent de VB5) je suis arrivé à travailler rapidement sur des tableau d'octets comme on le ferait en c++, en copiant un gros bloc depuis ou vers la RAM ou des fichiers.

Mais pour l'affichage tout reste en GDI ou GDI+ qui n'est pas accéléré. C'est le seul gros inconvénient de ces langages VB5 et VB.NET. C'est pour ça que le WPF me tenterais bien, et vos commentaires me rassurent (ouf le WPF n'est pas mort, et c'est un truc qui va durer)

Certains programmes faits en C++ avaient une vitesse d'affichage incroyable mais ils n'étaient compatibles qu'avec W95 et W98, ça ne tournait plus sous XP (ça devait donc être du bas niveau ou une bidouille dans le genre)

A l'école j'avais bien aimé java qui était un vrai langage POO tout en possédant pas mal de fonctions graphiques intéressantes et en étant multiplateforme. Mais je trouvait que c'était très lent, et je n'arrive plus à faire tourner mes programmes de l'époque (ils datent de 2001). Mais ça a peut être changé depuis, et si ils ont des bibliothèques 2D et 3D accélérées il faut peut être que je revienne au Java.

J'ai le sentiment de ne pas utiliser à fond VB.NET, mais en lisant les tutoriaux j'ai du mal à voir ce que j'ai raté... :?

De même, je ne suis pas satisfait de la façon dont je code... notamment tout ce qui est saisie et validation de données, et enregistrement dans des fichiers. C'est lourd et je recommence souvent les mêmes choses. J'ai essayé de me faire des procédures standard mais ça reste lourd.

D'un autre côte ce que je développe correspond quand même à beaucoup de calculs et de vérifications, et dans la CAO rien n'est simple, ce n'est pas une simple BDD de gestion de planning ou autres cas d'école.

Il y a aussi un autre truc qui frustrant et paradoxal : dernièrement j'ai passé du temps à optimiser mon gros programme en VB5. Sur certaines procédures j'ai amélioré le temps d’exécution d'un facteur 10 ! Mais optimiser conduit souvent à "casser" la belle programmation objet, car il faut limiter les appels multiples de fonctions, faire du code en ligne, quand c'est possible remplacer les tableaux et les collections par X variables standards, ect... :aie:

Le programme que je vais faire va à la fois manipuler plein de données liées entres elles de façon complexe (avoir une POO propre ne va pas être simple) mais en plus le code devra être optimisé... j'aimerais faire un truc très propre et élégant mais pour que ça marche ET que ce soit rapide j'ai peur d'avoir un code très bourrin au final :aie:

Je me prendrais bien un bookin pour revoir de A à Z la façon de programmer sous .NET et/ou WPF. J'ai envie de repartir à zéro, ce serai pas mal et ça me ferais du bien :-)
09/02/2015, 13h45
DonQuiche

Citation:

Envoyé par electroremy

Le programme que je vais faire va à la fois manipuler plein de données liées entres elles de façon complexe (avoir une POO propre ne va pas être simple) mais en plus le code devra être optimisé... j'aimerais faire un truc très propre et élégant mais pour que ça marche ET que ce soit rapide j'ai peur d'avoir un code très bourrin au final :aie:

Malheureusement on touche là à une des grosses limitations des langages dotnet :

* La réutilisabilité du code y est faible (pas d'héritage multiple ni de mixins, pas d'héritage pour les structures, génériques cent fois moins puissants que les templates c++ et moins puissants que ceux de Java, design des classes pré-lambdas et de WPF incitant à créer des types à foison, ...

* Il n'existe pas d'abstractions gratuites et chaque fonctionnalité se paie au prix fort : un énumérateur == une allocation, un lambda == une allocation, passage d'un type délégué vers un autre == une allocation, métaprogrammation par introspection (reflexion) == binaires trois fois plus lourds, ramage à tous les étages et règles de sécurité en panique, ...

* Le compilateur est à la ramasse : zéro optimisations chez MS, encore moins côté mono (le boxing sur foreach et using - merci Xamarin).

* Dans un contexte zéro-allocations ou CER C#/VB devient équivalent à un langage des années 80 puisqu'à peu près toutes les fonctionnalités y sont interdites.

C# brille dans les cas où tu n'as pas à te soucier des performances : écrire du code y est alors extrêmement rapide et il ne pêche que par sa faible réutilisabilité du code. Le reste du temps il te force à écrire le code le plus dégueulasse que tu aies jamais vu et il n'y a pas beaucoup d'astuces pour s'en sortir, et aucune que tu trouveras dans un livre sur le design objet.

EDIT : par contre la remarque de Pol63 ci-dessous sur le multithreading est très pertinente : en c# il est beaucoup plus facile qu'ailleurs d'exploiter plusieurs coeurs. Les primitives y sont pour beaucoup très bonnes et très simples, le modèle mémoire est clair et sensé, async/await font merveille pour l'UI et le déboguage est bien plus facile ici qu'ailleurs.
09/02/2015, 13h45
Pol63

sur la poo il y a aussi l'héritage et les interfaces (pas graphiques)
choses qui ne doivent pas exister sur vb5
et un autre truc pratique pour les performances, c'est le multithreading, là aussi inexistant à l'époque je pense

en .net on peut brasser des données sans passer par des tableaux et autre copie de bloc

j'ajouterais que comparer des langages côté performance n'est pas suffisant, un bon développeur QBasic fera toujours un programme plus rapide qu'un mauvais développeur C++
09/02/2015, 13h50
Pol63

Citation:

Envoyé par DonQuiche

C# brille dans les cas où tu n'as pas à te soucier des performances

d'un côté tu as l'air plus calé que moi sur les divers langages et ce qu'on peut en faire
d'un autre côté nous on a besoin de performance sur nos applis dans certains cas, et on les a en .net (on brasse des milliers de valeurs et on a des boucles de recherche de l'ordre de 20ms)
et on a du code concis
09/02/2015, 13h54
DonQuiche

Citation:

Envoyé par Pol63

d'un autre côté nous on a besoin de performance sur nos applis dans certains cas, et on les a en .net (on brasse des milliers de valeurs et on a des boucles de recherche de l'ordre de 20ms)
et on a du code concis

Mais des milliers de valeurs aujourd'hui, ce n'est rien, n'importe quel langage peut parcourir mille éléments en 20ms les doigts dans le nez (20ms = 80M instructions par coeur - dans cet intervalle on peut faire dessiner des dizaines de millions de pixels au GPU avec cent textures et des shaders long comme le bras, le tout en communiquant par un bus PCIe haute latence).

Par ailleurs ce qui est pertinent c'est moins la durée de cette recherche (c# n'a pas de raison d'être particulièrement lent à cet égard) que la durée du GC et la fréquence de ses passes et ses pauses, ce qui résulte des allocations inutiles incessantes produites par c#. C'est cette latence aléatoire induite le coeur du problème.
09/02/2015, 18h59
electroremy

Très passionnants ces échanges :D ... et un peu déprimants aussi :aie:

Ca me donne envie de tester un autre langage... ou de refaire du C++

Aussi, j'ai entendu beaucoup de bien de Python, ça vaux quoi par rapport à ce que je souhaite faire ?

A+
09/02/2015, 19h11
Pol63

au final ce qu'il faut en penser, c'est que le choix du langage se fait sur plusieurs critères dont :
- convient il techniquement à ce qu'on veut faire
- permet il de faire du code aussi performant que mon appli le nécessite
- le temps de développement nécessaire

en .net on peut faire beaucoup de choses, mais certaines applis nécessitent en effet un langage plus bas niveau
les points forts de .net c'est le temps de développement et la maintenabilité (enfin si c'est bien codé ^^)
qt est assez en vogue en ce moment à priori, et ca doit être un framework (graphique entre autre) de haut niveau sur C++ si j'ai bien suivi

après beaucoup d'entreprises ne se posent pas ces questions et se limite à partir dans une voie après peu de vérifications (faisabilité surtout)
et il n'y a que toi qui voit ce que tu veux faire, mais si tu as réussi à le faire en vb5 tu y arriveras forcément en .net
09/02/2015, 20h42
electroremy

Citation:

Envoyé par Pol63

après beaucoup d'entreprises ne se posent pas ces questions et se limite à partir dans une voie après peu de vérifications (faisabilité surtout)

C'est clair le choix d'un langage c'est comme se marier : ça engage pour la vie, certes le divorce est possible mais il coûte cher :mrgreen:

Citation:

Envoyé par Pol63

et il n'y a que toi qui voit ce que tu veux faire, mais si tu as réussi à le faire en vb5 tu y arriveras forcément en .net

J'ai déjà franchi ce cap; je ne suis pas à plaindre car ceux qui sont passés de VB5/VB6 à .NET sont nombreux et quand j'ai eu des problèmes j'ai toujours trouvé quelqu'un qui avait eu le même que moi - sauf juste une fois pour un truc mais j'ai trouvé la solution sans que ce soit trop difficile et je l'ai partagée ;)

LA question que je me posais c'est pour bénéficier de la fameuse accélération matérielle... histoire d'exploiter l'ordi à 40% de ses possibilités et pas à 4% :mrgreen: du coup WPF ou autre chose... et pourquoi pas faire quelques infidélités à MS et son VB (au sens large VB5/.NET)

Le C++, java et python, c'est tentant, il y a la possibilité de porter sur plusieurs plates formes... mais VB5 qui réussi à faire des .exe qui marchent aussi bien sur W95 jusqu'à Windows 8 c'est un vrai plus aussi pour la durée de vie du programme... et la facilité avec laquelle on peut faire des IHM complexes en VB5 ou en .NET est un énorme avantage qu'il est difficile d'abandonner.
10/02/2015, 19h19
electroremy

2 pièce(s) jointe(s)

Voici quelque chose qui va vous intéresser : j'ai retrouvé un vieux programme que j'avais fait en VB5 il y a dix ans.

C'était un programme d'affichage 3D maison, entièrement en VB5 :mrgreen: :weird: :aie:

J'ai fait une autre version de ce programme en VB5 en utilisant une API pour le traçage des triangles, et une autre en VB.NET, histoire de comparer les performances. ;)

Le code source et les .EXE des 3 versions sont téléchargeables ici : Pièce jointe 168699 ! fichier modifié voir mon post suivant

Hé bien les performances sont similaires : durée moyenne d'un affichage comprise entre 26 à 100 ms, pour chaque version (VB5, VB5 API et VB.NET)

Voici un screenshot : Pièce jointe 168700

Ce type de programme correspond assez à ce que doivent faire les gens qui font des applications avec un affichage graphique. Ce qui serait sympa, ce serai de faire une version de ce programme en WPF, mais aussi dans d'autres langages, histoire d'avoir une base de comparaison :D

A noter : les explications sur le fonctionnement de ce programme sont ici http://cidess.free.fr/coders-fr.html#3-1 (le code dispo sur le site n'est pas à jour, utilisez celui dans le fichier zip attaché à ce post sur le forum)

NB : je devrais peut être créer un sujet sur le forum général développement ?

A+
10/02/2015, 21h06
ShadowTzu

Lorsqu'on parle d'accélération matérielle, la solution la plus évidente est: DirectX, pourquoi ne pas l'envisager?
Par contre il faut que le matériel suit, l'accélération matérielle ne sert à rien si la machine n'est pas capable de faire fonctionner au moins windows xp.
10/02/2015, 22h08
electroremy

1 pièce(s) jointe(s)

Bonsoir,

j'ai modifié le code de mes trois exemples :
- image plus complexe
- meilleure gestion du DoEvents

Les résultats sont beaucoup plus intéressants, les temps d’exécutions sont stables, on obtient, en temps d'affichage :
- VB.NET (qui a une fonction Polygon intégrée) : 140 ms
- VB5 avec la fonction Polygon de l'API GDI : 196 ms
- VB5 standard : 292 ms

Il faut que je teste DirectX en VB5 et en .NET pour voir ce que ça donne

Voici les nouveaux fichiers source et .exe : Pièce jointe 168724

A+
10/02/2015, 22h25
electroremy

Citation:

Envoyé par electroremy

Il faut que je teste DirectX en VB5 et en .NET pour voir ce que ça donne

Quelle version de DirectX prendre pour VB5, et quelle version de DirectX prendre pour VB.NET ?

Tant qu'à faire je souhaite que mes programmes s'executent sur le plus grand nombre de machines (donc XP pour VB.NET et 98 voire 95 pour VB5)

Merci ;)
11/02/2015, 02h34
clementmarcotte

Bonjour,

Citation:

Envoyé par electroremy

Quelle version de DirectX prendre pour VB5, et quelle version de DirectX prendre pour VB.NET ?

Tant qu'à faire je souhaite que mes programmes s'executent sur le plus grand nombre de machines (donc XP pour VB.NET et 98 voire 95 pour VB5)

Merci ;)

Microsoft s'est toujours sacré des gens qui espèrent travailler en DirectX avec VB. Sauf peut-être quelque exceptions, Ils ne founissent leur exemples DirectX seulement en c++ ou en Caiguisé.

Pour utiliser DirectX en code managé, ils ont créé DirectX for managed Code avec Directx 9, si je me souviens bien. Depuis ce temps-là ils ne l'ont jamais mis à jour. Cela plante joyeusement avec des solutions x64 ou anycpu. Donc, c'est limité à des solutions x86 (32 bits) seulement.

Chez moi, avec Win 7 les dll sont dans:

C:\windows\Microsoft.NET\DirectX for Managed Code
11/02/2015, 08h07
Pol63

en wpf, mesurer le temps risque d'être peu évident
parce que je crois qu'il y a les objets qu'il faut pour faire ca, donc ca serait totalement différent
genre instancier un objet caméra, instancier un objet cylindre ... mettre éventuellement quelques lumières pour faire des effets de dégradé
le scroll serait juste un déplacement de caméra
et donc le code wpf ne fera pas grand chose à part définir la scène, c'est directX qui s'occupera du rendu et donc le temps sera déporté
il faudrait alors surcharger la scène pour la faire ramer et voir à l'oeil nu si ca rame moins en wpf
11/02/2015, 10h54
rv26t

Bonjour,

Citation:

Envoyé par electroremy

Quelle version de DirectX prendre pour VB5, ... ?

En vb5 et vb6 j'avais utilisé Directx7. (fonctionnel sous XP et Vista)
Il existe un livre sur VB6 et directX8 : Visual Basic et DirectX - Programmation des jeux (Wayne S. Freeze) édition CampusPress.
Mais c'est un peu vieux tout cela.
11/02/2015, 13h59
electroremy

J'ai une question à la con :

Dans mon petit programme j'ai besoin de dessiner en 3D à la fois des volumes (cylindre, cube, tore, ...), des surfaces (polygones triangulaires ou rectangulaires) et aussi des lignes et des courbes

Hors beaucoup de formats de fichier 3D et de code 3D ne prennent en charge que les polygones. Pour les volumes c'est facile il suffit de trianguler les surfaces... mais pour afficher des lignes ou des courbes ont fait comment ?

Je me vois mal remplacer chaque segment de droite par un cylindre de petit diamètre :aie:

Un format 3D et un moteur 3D qui prenne à la fois en charge volumes, surfaces, et courbes ça serait sympa

Vos réponses sur DirectX ne sont pas encourageantes... Quid de OpenGL ? Meilleur choix ?

A+
11/02/2015, 14h47
DonQuiche

Citation:

Envoyé par electroremy

...

Concernant les API graphiques bas-niveau pour dotnet... Les trois qui suivent sont largement utilisées :
* Monogame est multiplateformes, s'appuie sur Mono ou dotnet, sur DirectX ou OpenGL (OGL) selon les plateformes. C'est une version libre de XNA, qui était la bibliothèque 3D (et audio) pour dotnet mais a été abandonnée (même si elle fonctionne toujours). Cette bibliothèque est à un niveau légèrement plus élevé que DirectX ou OpenGL tout en restant bas-niveau. En termes fonctionnels c'est le meilleur choix à bas niveau mais il y a des bogues et son avenir n'est pas garanti même si plusieurs jeux et applis l'utilisent (Bastion par exemple) ; cela dit les biblios continueraient à fonctionner longtemps.

* SharpDX est le wrapper le plus populaire pour DirectX. Alternativement tu peux utiliser DirectX directement puisque nombre d'objects sont des objets COM, qui peuvent être directement consommés par dotnet, mais c'est en général lourdingue.

* OpenTK est le wrapper le plus populaire pour OpenGL. Cela dit OpenGL est un mauvais choix sous Windows du fait de drivers médiocres, en particulier chez Intel, et de drivers incorrectement installés. Par exemple Firefox désactivait l'accélération matérielle sur 50% des machines notamment à cause de problèmes de pilotes. Et même quand il y a des drivers OpenGL fonctionnels ils sont souvent à la bourre d'une ou deux générations d'API. En revanche OpenGL ES est le principal choix côté Android/iPhone.

Concernant les moteurs... Malheureusement les moteurs de jeux ne contiennent pas ce dont tu as besoin (courbes cubiques), leurs fonctionnalités te sont inutiles (ombres, occlusion ambiante, HDR, etc) et te poseraient sans doute plus de problèmes qu'autre chose (difficultés de contrôle du pipeline de rendu). Il faudrait voir du côté de moteurs 3D spécialisés mais je ne les connais pas et je ne crois pas que l'offre soit fabuleuse.

Au passage note que l'intégration de toutes les API 3D à ton API UI passe par les mêmes mécanismes avec les mêmes problèmes. A ce sujet WPF avait certains problèmes de performances, il me semble qu'ils ont été levés. Par contre tu as sans doute encore des limites telles que pas d'overlay transparent ou translucide par-dessus la zone 3D.

Enfin à propos des courbes... Les anciennes versions d'OpenGL incluaient un support natif des courbes cubiques (ou quadratiques ?) avec accélération matérielle. Ça fonctionne sans doute encore mais à mon avis de nos jours c'est émulé par le driver. Quant à DirectX ou OGL ES ils n'ont jamais supporté ça et je ne sais pas si les versions récentes d'OGL incluent encore cette fonctionnalité. Les techniques modernes utilisées pour l'émulation (applicables à n'importe quel API) sont la tesselation (on crée des polygones ou lignes à la volée - via le CPU ou via le GPU sur DX10+) et les pixel shaders (on dessine un bête rectangle et le shader va calculer pour chaque pixel s'il est sur la courbe ou non - cherche signed distance field spline). Mettre tout ça en oeuvre est loin d'être trivial mais peut-être trouveras-tu une biblio.
11/02/2015, 15h01
electroremy

Merci pour cet avis très détaillé

Je vais me renseigner sur SharpDX

Je vais aussi essayer de faire une version WPF, pour voir ce que ça donne

Dommage que Windows utilise mal OpenGL.

Dommage aussi pour les courbes et les lignes... Effectivement les moteurs 3D sont fait pour des appli ludiques, pas pour la CAO. Les éditeurs de soft CAO gardent jalousement leurs codes et astuces car leurs programmes se vendent cher

A+
11/02/2015, 15h35
DonQuiche

Citation:

Envoyé par electroremy

Dommage aussi pour les courbes et les lignes... Effectivement les moteurs 3D sont fait pour des appli ludiques, pas pour la CAO. Les éditeurs de soft CAO gardent jalousement leurs codes et astuces car leurs programmes se vendent cher

Non ça n'a rien à voir, d'autant que ces algorithmes de base sont vieux comme l'informatique et très bien connus et maîtrisés, et étaient déjà implémentés par les constructeurs. C'est simplement qu'il n'était plus justifié de consacrer des transistors et de la main d'oeuvre à un support matériel de ces courbes alors même que ces fonctions étaient utilisées par très peu d'utilisateurs et qu'il était devenu relativement facile de les émuler (ce qui n'était pas le cas à l'origine, quand les CPU étaient bien moins puissants). D'ailleurs le passage au mobile à poussé Khronos à faire le grand ménage et ne retenir que l'essentiel (apparition d'OGL ES et désormais convergence entre OGL et OGL ES avec une version unifiée, simple et généraliste). En fait on pourrait même dire que c'est le fait d'abandonner le monde de la CAO qui a sauvé OGL puisque cette API avait pris beaucoup de retard durant les années où le consortium se divisait sur les directions à prendre.

Et d'un autre côté c'est aussi symptomatique de la transformation des GPU qui étaient au départ des unités très spécialisées où chaque fonctionnalité était câblée, en processeurs programmables, généralistes et massivement parallèles (SIMD). C'était le passage du pipeline fixe au pipeline programmable. Une tendance qui n'a fait que se poursuivre avec le GPGPU et la quasi-disparition annoncée des API graphiques au profit d'API de calcul parallèle (DX 12, Mantle, etc).
11/02/2015, 17h58
ShadowTzu

SharpDX n'est pas compatible avec VB.NET, l'alternative c'est SlimDX.
11/02/2015, 18h03
DonQuiche

Citation:

Envoyé par ShadowTzu

SharpDX n'est pas compatible avec VB.NET, l'alternative c'est SlimDX.

Comment diable une bibliothèque dotnet pourrait-elle être incompatible avec VB.net ? Pourrais-tu préciser s'il te plaît ?

Quant à SlimDx de ce que j'en sais il est plus ou moins abandonné ce qui est une bonne raison pour ne plus l'utiliser.
11/02/2015, 18h09
ShadowTzu

c'est à cause de sa non sensibilité à la casse:
http://www.gamedev.net/topic/654944-...le-with-vbnet/
11/02/2015, 18h25
electroremy

Je vais aller voir du côté de SlimDX

Citation:

Envoyé par DonQuiche

En fait on pourrait même dire que c'est le fait d'abandonner le monde de la CAO qui a sauvé OGL puisque cette API avait pris beaucoup de retard durant les années où le consortium se divisait sur les directions à prendre.

:(

La question de savoir comment faire du graphisme performant, en 2D ou en 3D, pour une appli autre qu'un jeu ou que du multimédia revient pourtant très souvent sur les forums. Je vois des posts comme ça régulièrement sur les forums depuis la première fois que je suis allé sur le net en 1997 - d'ailleurs je suis surpris que des experts de ce forum me répondent, ils devraient êtres lassés de cette question à force :mrgreen:

Dommage qu'en 2015 les fonctions graphiques de base des langages les plus populaires ne bénéficient toujours pas de l'accélération matérielle, ou au moins d'un bon moteur 2D / 3D intégré.

La hantise du développeur disposant de peu de moyens et/ou de temps c'est de devoir faire tous les deux ans X versions de son logiciel pour suivre les évolutions des OS et des API.

VB et VB.NET ont une bonne durée de vie et une bonne compatibilité avec les différentes versions de Windows, mais le recours à telle ou telle API spécifique peut réduire fortement ces avantages. Si j'utilise SlimDX je vais être dépendant de lui, mes programmes ne pourront tourner que sur un PC qui supporte SlimDX, et si SlimDX est abandonné ou n'est plus supporté par une autre version de Windows il faudra tout recommencer.

Il y a la grosse frustration d'avoir une bonne idée, de pouvoir faire un logiciel répondant à un besoin, mais d'être bloqué par la nécessité d'être vraiment expert en programmation pour que l'application soit performante et utilise toute la puissance de l'ordinateur.

Je ne suis pas un expert en programmation, pour l'être il faudrait que ce soit mon métier principal ou alors que je ne fasse que ça. Par contre je commence à maîtriser des choses comme le traitement du signal ou la mécanique. Il me faudrait presque un langage pour non-programmeurs, mais permettant de faire de vraies applications. Une sorte de truc hybride à mi-chemin entre matlab et VB.NET (en fait ce n'est pas un bon exemple car matlab est loin d'être simple à utiliser mais je ne vois pas d'autre exemple à donner :aie:)

EDIT : donc SlimDX est abandonné :weird: :mrgreen: :aie: - il ne manque que un moteur 2D/3D intégré à VB.NET pour en faire le meilleur langage ; allez MS un petit effort :mrgreen:
13/02/2015, 01h51
electroremy

J'ai créé une version WPF de mon programme, voir ici sur le forum dédié : http://www.developpez.net/forums/d14...hismes-2d-wpf/