Discussion :

[electroremy]

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

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

[Franck.H]

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.

[Kropernic]

Quelques éléments de réponse ici ;-)

[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 ^^)

[DonQuiche]

Bonjour.

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é.

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.

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.

[electroremy]

Merci pour vos réponses

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

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...

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

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 :-)

[DonQuiche]

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

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.

[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++

[Pol63]

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

[DonQuiche]

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.

[electroremy]

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

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+

[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

[electroremy]

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

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% 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.

[electroremy]

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

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 : 3D_VB5_VB5API_VBNET.zip ! 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 :

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

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+

[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.

[electroremy]

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 : 3D_VB5_VB5API_VBNET_V2.zip

A+

[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

[clementmarcotte]

Bonjour,

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

[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

[rv26t]

Bonjour,

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.