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

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

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.