Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
cette phrase est peut-être ridicule mais je crois que je ne me suis pas fait bien comprendre.Envoyé par Bluedeep
Relire serait une bonne chose avant de juger hâtivement..
j'ai écris qu'un framework comme WPF à mon sens ne permet pas un contrôle totale des opérations.
Oui, et que je sache je ne t'ai pas contredit sur ce point (ce serait difficile). En revanche, tu as ajouté ça :
Ce qui est totalement ridicule et ne repose sur absolument rien de fondé.
Que WPF ne soit pas conçu pour faire une appli de CAO/DAO ou un simulateur de vol, personne n'en a, je pense, jamais douté, mais je ne vois pas en quoi cela contraindrait la taille des projets où il peut être utilisé.
Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
OpenGL + WPF
A mon avis, y'a la même chose, voir plus, avec directx. Donc... Y'a moyen de faire de la cao/dao avec wpf. Où est le souci ?
Pour moi aucun, c'est Mat.M qui affirme un tas de choses.
Pour ma part, je ne suis absolument pas spécialiste des IHM "pointues" (CAO, Simulateur, etc ....) donc je n'ai vraiment pas d'opinion sur le sujet; j'ai, en revanche, la prétention d'avoir un peu de bouteille sur les "gros" projets et c'est dans ce contexte que m'a fait bondir l'absurdité qu'il a proféré.
Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...
Une réponse vous a aidé ? utiliser le bouton
"L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel
on ne va pas polémiquer là-dessus ;je me suis très mal exprimé.
Evidemment qu'on peut utiliser WPF pour des gros projets ce que je voulais écrire c'est est-ce qu'on peut obtenir des performances optimales avec ce framework je laisse la question ouverte ?
Et puis l'iniateur de ce fil de discussion (DonQuiche) ne nous dit pas quelle solution au final il préfère..
Je n'ai pas encore dit quelle solution sera adoptée parce que ça reste en cours (période estivale, attente de détails sur les besoins fonctionnels, etc) et que nous ferons d'abord deux ou trois prototypes.
Sinon, concernant ce qui a été abordé par Mat. M, en vrac :
* Les pbs de performances sous WPF n'ont rien à voir avec dotnet en général. On peut faire de belles choses très véloces en dotnet en s'appuyant sur des API plus bas-niveau, malgré le coût de la barrière interop. Le surcoût CPU par rapport au C++ est d'environ 30% (davantage avec la barrière interop) mais puisque nos processeurs sont dix fois plus rapides que ce qui est nécessaire pour une UI moderne... Quant au GC, s'il ne bouffe que deux frames toutes les 10s, on peut faire avec...
* Le pb de WPF n'est pas non plus à chercher du côté de l'absence de contrôle lors des opérations de rendu. Il est plutôt à chercher du côté du databinding et de l'usage massif de la reflection, du côté du retained mode (lenteur des animations notamment), et peut-être d'une architecture logicielle foireuse avec déchaînement d’évènements en cascade qui rebondiraient dans tous les sens (ce n'est qu'une supposition, je n'ai pas creusé). Et si la nouvelle API pour les images (écrite en C) est deux fois plus lente que GDI pour lire un JPEG, ce n'est évidemment pas la faute de dotnet.
* Les pbs de tearing et autres ne sont pas non plus à chercher du côté de l'absence de contrôle bas-niveau : il est tout à fait possible d'éviter ces problèmes dans une appli dotnet en utilisant les mêmes composants bas-niveau que ceux sur lesquels s'appuie WPF. C'est tout simplement un défaut de compatibilité de WPF pour XP et une preuve du manque de support de MS pour cette techno.
* Si MS n'a pas utilisé dotnet pour Office & co, c'est sans doute parce qu'il aurait fallu pour cela réécrire toutes ces applis, tu ne crois pas ? Cela étant dit, plusieurs sites webs de MS ou encore Visual Studio reposent sur dotnet. Et MS s'oriente apparemment vers du tout dotnet puisque les nouvelles API du système viseront en priorité cet environnement. Et dotnet est largement mûr pour ce rôle. En revanche, ils ne s'appuieront pas sur WPF, c'est certain.
Enfin, je ne sais pas quelles sont tes compétences en C++ mais, concernant dotnet, ton avis ne vaut pas tripette.Beaucoup trop d'a priori en réalité très éloignés des faits. En revanche je te remercie pour ton avis sur Qt. MFC, par contre... Non ! Plus jamais. Que cette API meure en enfer.
La question c'est surtout : peut-on obtenir des performances suffisantes ?
La réponse est : ça dépend de ce que tu développes.
Et pour WPF, faut lire ça : http://msdn.microsoft.com/en-us/library/aa970683.aspx
1 on ne sait pas du tout quel type de projet tu développes.
Comme le précise l'intervenant précédent tout dépend du type de projet
Tu n'as absolument rien précisé là dessus.
C'est évident que si c'est un projet avec des webservices et architecture web, développer un projet avec des composants en C++ ne sera pas adapté.
en C++ j'ai plusieur d'années d'expérience et un peu moins en dotnet mais là n'est pas le problème,je ne suis pas idiot merci je comprends parfaitement à quoi sert WPFEnfin, je ne sais pas quelles sont tes compétences en C++ mais, concernant dotnet, ton avis ne vaut pas tripette.
tu écris que mon avis concernant dotnet "ne vaut pas tripette" alors j'arrive pas à comprendre ton problème.
Donc puisque je suis dans l'erreur la plus totale c'est que tu n'as aucun problème avec les technologies utilisées, c'est ce que j'en conclus...
( moi j'essaie d'être logique)
Donc tu n'aurais pas dû lancer ce fil de discussion est-ce que je me trompe ?
Puisque tu n'as pas de problèmes techniques.
tu as écris dans ton premier message "médiocrité des solutions" alors il faudrait être honnête et cohérent avec soi-même avant de dénigrer les autres merci.
c'est une grosse erreur de penser ça...
comme la capacité de traitement des CPU est maintenant bloquée que la fréquence n'augmente plus eh bien plus tu as des applis lourdes plus ça risque de ramer c'est logique...
c'est pour ça qu'Intel a développé des technologies comme le multicoeurs, l'hypertreading.
ben oui c'est ce que j'essaie d'expliquer ça fait plusieurs messages.
Or je veux bien croire que WPF soit performant mais pour ma part je demeure un peu sceptique notamment à la description faite par DonQuiche.
Sans continuer à polémiquer je dis "faut voir" ; c'est à DonQuiche de déterminer
Bien que cela commence à dater, je tenais à offrir une remontée. Au final nous avions choisi WPF car aucune plateforme n'est aujourd'hui adaptée et parce qu'elle est celle qui offre le moins d'inconvénients. Voici un récapitulatif de mon jugement sur les différents frameworks pouvant sérieusement prétendre à pouvoir satisfaire des UI modernes.
* Qt ne faisait malheureusement pas l'affaire : bien que très rapide en général, les performances baissent drastiquement dans le cas d'animations lourdes (la bibilio n'a pas été prévue pour ça en dépit d'ajouts tardifs) et les problèmes de vsync n'étaient pas absents. Qt offrait certes des moyens de contourner cela mais il fallait alors allait tremper dans le rendu en OpenGL et autres bidouilles plus raisonnables mais sacrifiant une bonne part de la productivité. Au final, le surcoût en travail ajouté à une productivité dejà bien inférieure à une solution dotnet a eu raison de cette option. En somme les évolutions ne compensent pas le fait que cette biblio n'a pas été conçue pour les besoins actuels.
* Qt Quick est un sous-ensemble récent de QT, destiné au mobile mais pleinement utilisable pour le bureau. Si je devais le comparer à WPF, auquel il m'a beaucoup fait penser, je dirais qu'on a très sagement sacrifié certaines fonctionnalités (layout simplifié mais astucieux, pas de databinding ou de MVVM) afin d'offrir d'excellentes performances, tout en améliorant certains points (QML est basé sur JS/JSON et est beaucoup plus sympa que XAML, insertion astucieuse et parcimonieuse de JS dans le QML possible et désirable, etc). Le modèle JS / C++ n'est certes pas le plus sexy qui soit mais il fonctionne bien. Du coup, je vais être assez radical : pour moi c'est LA techno qui répond aux besoins actuels de ceux qui veulent vraiment faire des UI impressionnantes et performantes, ses auteurs ayant fait un excellent arbitrage lors de la phase de conception. Malheureusement, elle est jeune et il faudra sans doute encore un an et Qt5 (afin de résoudre les problèmes de vsync - encore !) plus quelques widgets pour qu'elle soit vraiment mûre (la préoccupation initiale était le mobile et cela se sent, mais à l'avenir Qt Quick sera aussi la solution de référence pour le bureau). Or il nous a semblé que travailler depuis une beta en misant sur la timeline floue de Nokia était trop hasardeux. A surveiller de très près toutefois !
* Flex ne nous attirait pas des masses : un "truc" avec de l'actionscript, un langage déclaratif plus atroce encore que XAML, un tooling et un écosystème limité, des logiciels de chez Adobe, une communauté restreinte... Ça sentait le roussi. Et il n'y a pas eu de surprise : les performances ne sont pas au rendez-vous, l'ensemble est sujet à des fuites mémoires, la productivité n'est pas excellente, etc. C'est peut-être une alternative à html/js pour le mobile mais, pour le desktop considéré isolément, je ne vois guère l'intérêt.
* Html + JS. Performances faiblardes, productivité faiblarde ou trop de contraintes (pas conçu pour des UI riches à l'origine), problèmes de vsync fréquents, etc, etc. Là aussi, pour du desktop considéré isolément, ça ne se justifie pas à moins de n'avoir une équipe web sous la main.
* WPF. Performances standard faiblardes mais supérieures à tous les autres frameworks à l'exception de Qt Quick (bien que Qt offre de coûteux moyens d'aller au-delà des perfs de WPF), des problèmes de vsync mais, là aussi, comme tous les autres frameworks modernes, la meilleure productivité parmi toutes les solutions.
Au final, donc, WPF l'emporte comme étant celui avec le moins d'inconvénients. Qt Quick obtient quant à lui le prix d'honneur du jury du fait de sa jeunesse extrêmement prometteuse. Enfin, Qt décroche une mention honorable parce qu'il a au moins le mérite, certes au prix de coûteux efforts, de permettre la réalisation d'une UI de haute qualité.
Sympa le retour ! Ca mériterait un article
Avez-vous fait un choix d'architecture / framework UI ?
Bonjour Luckyluke34.
Ayant choisi WPF, nous avons évidemment opté pour le MVVM, ça allait de soi. Maintenant, en amont de notre choix, les architectures possibles pour chaque framework n'étaient pas déterminantes en elles-mêmes, elles étaient simplement un des facteurs de productivité du framework.
Maintenant, pour un éventuel article, le temps me fait défaut en ce moment, je manquerais de détails sur quelques technos que je n'ai pas personnellement évaluées en profondeur (le travail fut partagé) et je pense que l'approche retenue et les besoins (être près à s'adapter à un autre langage et une autre plateforme ; orientation Windows uniquement avec une équipe plutôt éloignée des technos web ; souci de la fluidité et de la réactivité quitte à ce que la productivité en pâtisse) ne sont de toute façon pas très communs de nos jours.
Enfin, tout de même, une chose que j'ai oubliée de signaler et qui m'a vraiment surprise : les problèmes de vsync. Ce n'était pas un problème il y a 30 ans (Amiga, Amstrad, etc), ce n'en n'était pas un il y a 10 ans (GDI) et, soudain, voilà que toutes les technos semblent avoir oublié ce point pourtant essentiel. Notamment, voir ce défaut sur WPF (au moins sur XP) et Qt Quick (en attendant Qt5 - première moitié 2012) est vraiment désolant.
Autre chose : au final, nous nous sommes résignés à revoir nos ambitions à la baisse. Puisqu'il n'est pas possible de façon réaliste (sans avoir à coder la moitié de l'appli en OpenGL ou DX) d'avoir un résultat fluide, l'utilisation d'animations sera très parcimonieuse.
Framework RIA/JS + assemblage dynamique
Sans aucune hésitation, je vote pour HTML/JS, avec un framework RIA et des mesures complémentaires, pour éviter les écueils.
Côté client, les frameworks RIA égalent depuis des années en ergonomie le client lourd : grilles modifiables, personnalisables au runtime, arbres multi-colonnes, formulaires, fragments composites, avec maître-détail en cascade. On dirait des applis Delphi qui tournent en ligne
Voici un exemple, side-by-side Delphi/ExtJs:
Puis, comme on est en ligne, les fonctionnalités collaboratives et la traçabilité deviennent obligatoires, tout comme dans un wiki.
Cependant, pour ne pas perdre en productivité, qualité et évolutivité, il faut prendre des mesures complémentaires indispensables, à l'aide d'un framework côté serveur. Pour ma part, je pratique (depuis toujours) l'assemblage dynamique de composants macroscopiques à partir d'un dictionnaire déclaratif. On peut commencer en XML avec Spring, puis placer le "dico" dans une base de données ...
En poussant le paradigme jusqu'au bout, on finit par tout y mettre : données, structure, programmes (avec code éventuel et tests unitaires), outils de modélisation et même gestionnaire de versionsDu coup, en quelques minutes on fabrique une appli riche évolutive. ]
Noter bien le changement de l'héritage de dernière minute (index 2'50")
A bientôt dans le cloud
@karmiczam
J'aime beaucoup le "avant/après" comparant deux applis avec dix ans d'intervalle pour vanter une solution tout à fait inadaptée au problème posé. Pas de doute, tu ne souhaitais que faire la promo déguisée de ton produit, comme au travers de tes deux autres messages sur ce forum.
Me voici démasqué. Il est bien connu, les voyageurs du futur doivent respecter la première directive, ne pas influencer l'histoire et éviter la contamination culturelle
Plus sérieusement, si tu tiens à tout prix à coder pour toute chose concernant l'UI et rester en C# avec un client lourd natif (ou presque), la quête est respectable. Si le poids du code existant et des connaissances des développeurs pèse, c'est compréhensible. Moi, j'avais donné - de toute évidence, à tort - plus de poids à l'expression "UI moderne", en considérant qu'elle devrait pouvoir s'exécuter de partout.
En revanche, si ce ne sont pas de vraies contraintes et tu es prêt à te libérer de la constante gravitationnelle d'une plateforme (le C# n'est pas du tout un problème car il faut bien quelque chose pour mettre le couvercle sur le serveur), il peut y avoir un joli échange d'arguments, basé sur des métriques, patterns, assemblage dynamique, indicateurs d'agilité et d'entropie, modèles fractals, réflexion, etc. On peut aussi jeter un regard Darwinien sur la question, observer les tentatives d'abstraction des différents langages, paradigmes et frameworks hors de son cadre du moment, s'y inspirer, bâtir finalement sa propre solution et revenir en parler. Mais là, le risque est de croiser une version antérieure de soi-même, légèrement jalouse et de se faire taxer de frimeur en Porche.
Amicalement, peut-être à un beau jour dans le cloud
@karmiczam
// Time travel masterclass on demand
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager