arno53 a écrit :



Pour Apple y’a pas vraiment de mouvent d’unification pour l’instant … Cocoa et Cocoa Touch reste assez éloigné l’un de l’autre d’après ce que j’ai compris et il est pas possible de récupérer une grosse partie de l’App iOS pour la porter vers Mac… Apple se contente juste de proposé ses apps (Plan) ou certaines fonctionnalité sur ses 2 support.



Pour Google, ils ont annoncé à la Google I/O que les apps Android tourneront sur Chrome OS mais ils n’ont pas plus détaillé que ça " /> C’est soit les apps Android qui tournent dans NaCl sur Chrome(OS) ce qui serait vraiment très intéressant soit juste que le nom de l’application qui pointe vers la version Android (Java) et vers la version Web App (javascript/html ou en C via NaCl je crois) mais là pour le coup d’un point de vu développement ca change pas grand chose " />



Pour Ubuntu, est ce que les apps sont sandboxé par défaut ? Ca serait a la limite le point faible de la solution si ce n’est pas le cas … Enfin le plus gros problème reste les part de marché et la visibilté " />



En tout cas si Microsoft peut enfin unifier tout ce qui touche au XAML en prenant les points fort de WPF et Silverlight ca va vraiment devenir intéressant … Il faudra surement attendre 2020 et la fin de support de Windows 7 pour que ça soit massivement utilisé (et a condition que ca soit retroporté sur Windows 8) mais c’est deja un bon pas en avant …



Par contre j’ai l’impression qu’il y’a pas mal de critique sur les performances du XAML … True or not ?







les rumeurs disent que win9 sera une maj gratuite pour win7/8. La base installée devrait rapidement être beaucoup plus grande que celle d’iOS. Nul besoin d’attendre 2020 donc.





concernant XAML et les perfs tout dépend de l’implémentation.



la toute première techno exploitant du XAML était WPF.

il est accéléré matériellement et beaucoup plus performant que GDI+. Mais les performances sont loin d’être aussi bonnes qu’elles pourraient l’être.



le modèle interne de WPF est taillé pour fournir une certaine compatibilité avec les technos Windows legacy (GDI, automation, COM,…) et donc WPF a une certaine lourdeur comparé à Silverlight qui n’a pas eu à supporter ces technologies.

au niveau du rendu, WPF datant de 3ans avant la sortie de Direct2D, il utilise son propre moteur de rendu et a pas mal de défauts (les ellipses par exemple sont très lentes à dessiner car constituées de centaines de triangles dessinés par le GPU).



Silverlight et WINRT utilisent l’accélération matérielle pour la composition et la mise en cache des bitmaps, mais pas pour le rendu des éléments de base qui se fait toujours en software.



paradoxalement, la plupart du temps Silverlight et WinRT/XAML sont plus performants que WPF.



MS a annoncé que winRT/XAML allait bientôt utiliser direct2d et sera donc entièrement accéléré matériellement. Je pense que c’est l’api dont il est question dans cette news.



en attendant, ça peut paraitre dingue, mais à part utiliser direct2d directement en c++, le moteur de rendu le plus performant pour les interfaces graphiques en WinRT et desktop, c’est HTML/JS via le moteur de rendu d’IE10/11.



sinon pour revenir à WPF, faute de mieux je reste toujours assez fan.



j’ai même réalisé une alternative à l’explorateur Windows en WPF.

je me suis heurté à pas mal de soucis de perf, notamment sur les Intel Atom Clover Trail dont la partie graphique est lente et supporte très mal WPF (alors que les applis winRT sont beaucoup plus fluides sur la même machine).



http://www.julien-manici.com/immersive_explorer/

Bejarid a écrit :



[mode d’jeuns]

Comment que t’y connais rien en GPU ça fait pitié mec !

[/mode d’jeuns]



Un GPU c’est faire pour tourner lentement mais parallèlement, comme les pixels des écrans. Au contraire d’un CPU qui doit enchainer vite. Donc chaque synchro est une perte sèche.



Il n’est pas question de 2D ou de 3D (la 3D de WPF est encore pire que sa 2D en terme d’optimisation), mais bien de DrawCall qui sont permanents et quasi tous inutiles. La première critique que tout le monde à fait (y compris des gens de chez MS) c’est l’absence totale de regroupement des formes dessinnées. Toutes les autres BU de MS ont fait mieux, par exemple IE9, sortie à peine après WPF, qui lui aussi fait appel à DirectX, mais nettement mieux. Les gens qui ont fait WPF avaient juste pas le niveau en moteur graphique. Ceux qui ont fait WinRT (potentiellement les mêmes mais plus expérimentés) l’avaient bcp plus, d’où des perfs incomparables.



Cesse de jouer au plus malin et renseigne-toi un peu avant de parler d’un sujet dont manifestement tu n’as même pas les bases.









IE9 sorti à peine après WPF?



WPF est sorti en 2006, et était en développement depuis 2002.



IE9 est sorti en 2010 en s’appuyant sur Direct2D et DirectWrite apparus en 2009 avec win7.



il y a quand même pas mal d’années entre ces technos, et on peut pardonner à l’équipe du .net Framework de ne pas avoir eu l’expertise d’une équipe entièrement dédiée à la création d’une API graphique.



je ne pense pas qu’il faille s’attendre à des améliorations aux niveau de WPF. MS ne voudra pas prendre le risque de casser la compatibilité.



l’avenir c’est WinRT/XAML, qui lui contrairement à WPF va évoluer régulièrement avec chaque nouvelle version de Windows.



j’espère juste qu’on aura la possibilité de l’utiliser sur le desktop (hors sandbox) comme api graphique en remplacement de WPF.



ce serait dommage que les applis pro qui peuvent pas migrer vers WinRT à cause de la sandbox ne puissent pas profiter des améliorations de perf.

Bejarid a écrit :



WPF a été developpé par une équipe spécifique, constitué exprès, pas par l’équipe BCL (celle qui gère le coeur de .Net). Ensuite le WPF qu’on connait aujourd’hui est celui de la version 3.5.1, (après ça n’a plus évolué) sortie le 18/11/2008. Ca fait donc un an et demi avant la sortie du moteur d’IE9, c’est pas franchement énorme, et pourtant le gap technique était clairement là (surtout au niveau des drawcall, le truc le plus simple à analyser).



Mais non, je n’accuse pas l’équipe WPF d’avoir salopé le boulot, c’est juste que clairement ils n’avaient ni les compétences ni le temps pour optimiser la chose. A coté, t’as l’équipe IE9 qui a obtenu de l’équipe DirectX de l’aide, et qui donc a réussit. Et WinRT a continué sur ces acquis.



C’est bien pour ça que je disais que tout gain de perf passera par une intégration plus forte entre le framework graphique et une équipe de MS qui s’y connait en moteur graphique (en priorité l’quipe DirectX donc). Et pour le faire correctement, rien de mieux que de le mettre dans les specs de départ… Ca tombe bien, DirectX12 est encore en developpement !



Tous les espoirs sont donc permis.









même en version 3.5.1 il n’y a pas eu changement en profondeur par rapport à la toute première version de WPF (3.0). Tout le boulot autour de WPF remonte à 2006 et avant.



mais bon je pense qu’à cette époque WPF devait déjà être conçu comme technologie de transition. Le but était pas d’avoir des perfs optimales, mais quelque chose qui puisse être utilisable par des développeurs Windows en entreprise qui peuvent pas jeter le legacy par la fenetre du jour au lendemain.



déjà en 2003 à l’époque de Longhorn on parlait déjà de modèle d’applis sandboxées. Ca a mis 10ans à se concrétiser avec WinRT. Et MS devait savoir déjà en 2006 que .net/WPF elle même ne serait pas utilisé comme API pour ce nouveau modèle d’application en l’état.

mais les idées autour de WPF et l’expérience de MS auront permis de faire mieux avec D2D et WinRT/XAML en évitant les erreurs de l’équipe WPF (plus jamais de BitmapEffect!)



au passage, WPF a été conçu pour être accéléré matériellement par du hardware directx9… Et directx7!

en fait un membre de l’équipe wpf avait dit à l’époque que tout à l’intérieur de WPF était basé sur les limitations de direct3d 7. Et il était question avec WPF4 de se baser uniquement sur dx9, mais apparemment ce développement n’a pas eu lieu.



donc effectivement on est assez loin de direct3d 10 et de direct2d en terme d’efficacité.