Qt 5.5 RC et plans pour les prochaines versions

La version RC vient de sortir, corrigeant uniquement des défauts par rapport aux préversions précédentes. L’objectif actuel est d’avoir une version finale le premier juillet (avec un retard de plusieurs mois sur les plans).

Qt 5.6 devrait être la dernière compatible avec une série de combinaisons de plateformes et de compilateurs : plus de GC 4.6, d’OS X 10.7, de Windows Embedded Compact 7, de QNX 6.5 — Qt 5.7 devrait faire le ménage dans sa compatibilité, pour ne garder que les versions les plus récentes, ce qui ira de pair avec une migration complète vers C++11 (le code n’aura plus l’obligation de compiler en mode C++98). Cette version 5.6 aura cependant un support à long terme de deux ans pour tous ceux qui ne peuvent pas encore effectuer de migration, tandis que la 5.7 laissera plus de temps pour modifier le code plus en profondeur.

Cependant, les modules Qt Quick 1 et Qt WebKit ne seront plus inclus dans les binaires distribués, la relève étant déjà assurée (Qt Quick 2 et Qt WebEngine, même si ce dernier n’est pas exempt de débats). Qt Script devrait faire ses adieux avec Qt 5.7.

Sources : [Development] QtCS: Long Term Release discussion, [Development] Qt LTS & C++11 plans

Sortie de Unreal Engine 4.8, version focalisée sur la stabilité

Trois mois et demi après la précédente version, la nouvelle mouture d’Unreal Engine est disponible, numérotée 4.8. L’un des points majeurs de cette version est la stabilité de l’éditeur et des jeux, en prenant en compte la plupart des bogues courants et des plus petites demandes de fonctionnalité. L’éditeur et le moteur d’exécution devraient ainsi être plus solides. Notamment, le portage de l’éditeur vers Linux est bien avancé, même s’il ne sera pas possible de lancer des jeux.

L’avenir de Qt 4.8 passe-t-il par CopperSpice ?

La dernière version de maintenance de Qt 4.8 est sortie, numérotée 4.8.7. Qt 5.0.0 est sorti fin 2012 ; l’un des objectifs était de garder une grande rétrocompatibilité avec les versions précédentes, pour faciliter la transition.

Cependant, certains développeurs ont préféré effectuer des changements plus profonds dans Qt 4.8, notamment afin d’exploiter les templates C++ et les nouveautés de la norme C++11. Leur travail a donné naissance à CopperSpice, dérivé de Qt 4.8. L’un des points essentiels est la disparition du moc, le compilateur de métaobjets utilisé par Qt depuis ses débuts. Ce générateur de code servait, dans les années 1990, à pallier les manques du C++ à l’époque, qui rendait impossible l’implémentation de systèmes comme les signaux et slots (également implémentés dans Boost.Signals dès le début des années 2000, sans tel outil).

Ce n’est pas la première fois que l’obsolescence de cet outil était pointée du doigt, malgré les justifications apportées dans la documentation. L’un des défauts couramment rapportés est l’impossibilité d’utiliser les templates avec ce système de métaobjets, mais également la performance (comparaisons de chaînes de caractères à l’exécution) — CopperSpice cite d’ailleurs dans sa documentation une liste d’inconvénients. Récemment, des preuves de concept ou des réflexions avancées ont été proposées pour s’en passer ou l’inclure au niveau du compilateur.

CopperSpice se défait donc complètement de cet héritage du passé, remplacé par C++11. Par conséquent, du code utilisant CopperSpice n’a pas besoin d’outil externe pour sa compilation, ce qui pouvait rendre les choses plus compliquées pour l’intégration avec du code C++ existant ; le code C++ utilisant Qt peut être transformé à l’aide d’un outil automatique de traduction, baptisé PepperMill. Il intègre également des nouveautés de Qt 5. De même, la compilation se fait avec les GNU AutoTools, certes plus répandus que qmake, mais pas forcément plus modernes (contrairement à CMake, par exemple). L’un des objectifs à plus long terme est de remplacer les conteneurs de Qt par leurs équivalents de la STL (ce qui évite de les recoder).

Cette manière de procéder pose cependant question : était-il nécessaire de créer un nouveau projet pour “juste” se débarrasser du moc, c’est-à-dire s’écarter d’une grande communauté ? Pourquoi repartir d’une version aussi ancienne (Qt 4.8.2 date de mai 2012), alors que Qt 5 a justement permis beaucoup de nettoyage ? Les développeurs de CopperSpice ont aussi leur propre version de Doxygen pour la documentation (renommée DoxyPress). L’univers Qt Quick ne fait pas partie des fonctionnalités de CopperSpice.

Sources : annonce de CopperSpice, site officiel, discussion sur Phoronix.

Controverse sur l’utilisation de NVIDIA GameWorks dans Witcher 3

NVIDIA GameWorks est l’ombrelle sous laquelle NVIDIA propose une série de technologies d’effets pour des jeux. Leur principal avantage est d’être déjà implémentés et optimisés par NVIDIA, les développeurs des jeux peuvent donc ajouter un surcroît de réalisme à leurs productions sans toutefois y passer des semaines ou des mois. Ce programme contient notamment leur moteur physique PhysX et les diverses extensions APEX (Clothing, Destruction, etc.), mais aussi des bibliothèques d’occlusion ambiante (HBAO+), d’illumination globale (GI Works), de rendu de visages (FaceWorks), de poils et de cheveux (HairWorks) ou d’océan (WaveWorks). Avant ce programme, NVIDIA proposait déjà ce genre d’effets, mais sous la forme de code à intégrer au jeu, pas comme bibliothèque externe, ce qui en limitait l’utilisation.

Cependant, ces outils peuvent poser question : ils ne sont accessibles qu’aux studios de développements (bien que certaines parties soient déjà intégrées à Unreal Engine 4 et que FleX est téléchargeable seul), leurs sources ne sont pas disponibles… y compris pour les fabricants de cartes graphiques concurrentes comme AMD ou Intel. Ainsi, ils ne peuvent pas optimiser ces bibliothèques pour leur matériel, contrairement à NVIDIA — une pratique courante dans l’industrie.

Le problème, dans le cas de Witcher 3, c’est que la performance du jeu décroît sensiblement en activant HairWorks sur des GPU sans caméléon. Un des développeurs précise :

Many of you have asked us if AMD Radeon GPUs would be able to run NVIDIA’s HairWorks technology – the answer is yes! However, unsatisfactory performance may be experienced as the code of this feature cannot be optimized for AMD products. Radeon users are encouraged to disable NVIDIA HairWorks if the performance is below expectations.

De même, Project Cars a tendance à nettement moins bien fonctionner sur du matériel AMD que NVIDIA. Il utilise des technologies GameWorks, contrairement à d’autres jeux du même genre qui ne souffrent pas d’un grand écart de performance ; notamment, la simulation physique des voitures utilise PhysX, qui peut utiliser les cartes NVIDIA pour une partie des calculs grâce à CUDA, contrairement aux cartes AMD — désactiver les calculs physiques sur GPU pour une carte NVIDIA donne également des problèmes de performance.

D’autres jeux utilisant la même technologie n’ont pas ce genre de problème, comme FarCry 4 : activer HairWorks diminue certes le nombre d’images par seconde d’une dizaine d’unités, mais indépendamment de la marque du GPU utilisé, tant sur du matériel NVIDIA que AMD (récent et de haut de gamme des deux côtés), selon Far Cry 4 Graphics Features Performance Review: Fur Performance.

Ces critiques ne sont pas récentes, mais ce n’est qu’en avril 2014 que NVIDIA a commencé à offrir des licences pour ces technologies incluant le code source, en fonction du degré de maturité du code, soit après les premières utilisations dans des jeux finalisés. Peu après, deux ingénieurs ont avoué que les développeurs de jeux utilisant GameWorks n’étaient pas autorisés à travailler avec AMD pour optimiser leur code (en juillet 2014).

La réponse de NVIDIA à ce sujet apporte des précisions intéressantes à ce sujet :

We are not asking game developers do anything unethical.

GameWorks improves the visual quality of games running on GeForce for our customers. It does not impair performance on competing hardware.

Demanding source code access to all our cool technology is an attempt to deflect their performance issues. Giving away your IP, your source code, is uncommon for anyone in the industry, including middleware providers and game developers. Most of the time we optimize games based on binary builds, not source code.

GameWorks licenses follow standard industry practice. GameWorks source code is provided to developers that request it under license, but they can’t redistribute our source code to anyone who does not have a license.

The bottom line is AMD’s tessellation performance is not very good and there is not a lot NVIDIA can/should do about it. Using DX11 tessellation has sound technical reasoning behind it, it helps to keep the GPU memory footprint small so multiple characters can use hair and fur at the same time.

I believe it is a resource issue. NVIDIA spent a lot of artist and engineering resources to help make Witcher 3 better. I would assume that AMD could have done the same thing because our agreements with developers don’t prevent them from working with other IHVs. (See also, Project Cars)

Elle est en tout cas appuyée par des faits vérifiés à l’extérieur : la performance en tessellation est bien meilleure chez NVIDIA qu’à la concurrence. Ces différences en performance seraient donc dus à une exploitation intensive de la part de NVIDIA des parties qu’ils savent bien fonctionner chez eux. Sciemment ou non, cela a eu des impacts négatifs sur le matériel AMD — sans interdire toute optimisation par AMD.

Sources : Nvidia Responds To Witcher 3 GameWorks Controversy, PC Gamers On The Offensive, message de Marcin Momot, message de 007sk2, Far Cry 4 Graphics Features Performance Review: Fur Performance, NVIDIA and AMD Fight over NVIDIA GameWorks Program: Devil in the Details, The NVIDIA GeForce GTX 980 Review: Maxwell Mark 2

Qt WebEngine : le problématique empaquetage de KDE

Qt 5.4 est venu avec une énorme nouveauté, Qt WebEngine, une intégration de Chromium (le projet libre derrière Google Chrome) pour l’intégration de contenu Web dans des applications Qt. Chromium est un véritable navigateur, avec notamment une pile réseau complète, construit sur Blink, un moteur de rendu dérivé de WebKit. L’objectif est de déprécier Qt WebKit assez rapidement.

Ce nouveau module est d’ores et déjà utilisé par certaines parties de KDE 5, comme KDE PIM, un outil de gestion des informations personnelles.

Avis des mainteneurs

Pourtant, ce mouvement ne se fait pas sans à-coup, notamment du côté des mainteneurs de KDE pour Debian et Fedora, par la voix de Lisandro Pérez Meyer. Leur grief est que Qt WebEngine est un composant logiciel très difficile à empaqueter, notamment à cause de ses nombreuses dépendances. En elles-mêmes, elles ne posent pas de problème ; cependant, Qt WebEngine les intègre dans ses sources avec des modifications, ce qui empêche d’utiliser les versions installées à l’échelle du système. Cette manière de procéder consomme plus d’espace disque et plus de mémoire, mais aussi complique la tâche lors de mises à jour de sécurité (chaque binaire doit alors être mis à jour séparément, plutôt que la copie globale).

Cette difficulté est déjà présente au niveau de Chromium et explique à elle seule pourquoi ce navigateur n’est pas inclus dans Fedora. En plus, le moteur JavaScript V8 manque de portabilité : WebKit contenait une couche d’abstraction du moteur JavaScript, que Blink (donc Chromium) a abandonné, ce qui force l’utilisation de V8. Pour Fedora, le problème est mineur, puisque V8 est compatible avec toutes les plateformes majeures visées par la distribution ; par contre, des outils comme Qt Assistant, s’ils passaient sur Qt WebEngine, ne pourraient plus fonctionner sur les plateformes secondaires (comme ARM 64 bits — dite AAarch64 —, PowerPC ou s390 — utilisée par les IBM System z).

De plus, la compilation des informations de débogage est pratiquement impossible, à cause de la quantité astronomique de RAM utilisée par l’éditeur de liens (plus de huit gigaoctets) — en augmentation depuis Qt WebKit, qui n’était déjà pas connu pour sa facilité de compilation.

Réponse des développeurs

La réponse que font les développeurs de KDE aux mainteneurs des distributions n’implique pas de grands changements du côté du développement de Qt WebKit ou de Chromium : selon Albert Astals, l’objectif d’une distribution est de fournir les logiciels demandés aux utilisateurs ; si leurs règles ne leur permettent pas de distribuer ces logiciels, c’est qu’il faut adapter les règles.

Au contraire, Franz Fellner propose d’adapter les applications : pourquoi forcer l’utilisation d’un moteur aussi complexe que Chromium quand les besoins sont relativement limités, comme afficher des courriers électroniques ?

D’autres avis sont encore plus tranchés, comme celui de Kevin Kofler : puisque Chromium n’en a cure de l’empaquetage, il faudra que Qt en maintienne sa propre version… ou déprécier le module Qt WebEngine au profit de Qt WebKit !

Sources : Distros and QtWebEngine (discussion), Deprecating modules with 5.5 (message de Kevin Kofler)

Compatibilité avec Windows 10

L’actualité Windows est actuellement trépidante, les détails sur la nouvelle version du système d’exploitation arrivant régulièrement, en prévision d’une sortie officielle cet été. Quel degré de compatibilité Qt propose-t-il avec cette nouvelle version ? Toutes les applications Qt qui fonctionnaient sur les versions précédentes de Windows continueront à tourner, sans limitation, qu’il s’agit d’applications traditionnelles (Win32) ou modernes (WinRT, Windows Store).

Par contre, ces applications pourraient présenter des dysfonctionnements par rapport aux nouvelles fonctionnalités, comme le mode fenêtré des applications modernes (elles ne sont plus limitées au plein écran) : les versions actuelles de Qt présentent quelques défauts lors du redimensionnement, qui seront corrigés avec Qt 5.5 ; également, le style n’est pas automatiquement adapté à WinRT. Qt est d’ores et déjà testé avec les préversions de Visual Studio 2015, même si le support officiel ne sera disponible qu’à sa version finale (Qt 5.5 devrait être disponible avant Windows 10 et Visual Studio 2015).

Comme toujours avec Qt, le même code pourra être utilisé pour plusieurs déploiements d’une même application : le même code pourra servir pour OS X, Linux, Windows, mais également pour WinRT.

Une nouveauté non technique du port de Qt 5.5 vers WinRT sera la licence, comme pour de précédents modules : il s’agira d’une double licence LGPL 3-GPL 2+ (en plus d’une licence commerciale), compatible avec les termes et conditions de déploiement sur le Windows Store.

Source : Windows 10 Support in Qt

Sortie de qbs 1.4.0

qbs est un système de compilation prévu pour remplacer qmake pour les projets Qt. La description des projets se fait en QML. L’outil est certes prévu pour Qt, mais a une vocation plus généraliste : il peut être utilisé pour tout type de projet C++ (comme qmake).

La version 1.4.0 vient avec quelques nouveautés intéressantes, comme l’ajout de projets Android : qbs est maintenant capable de compiler des projets pour Android, qu’ils contiennent du code natif ou non (tant avec le SDK que le NDK, donc) ; cette fonctionnalité n’a pour le moment rien de spécifique à Qt et n’est pas intégrée à Qt Creator.

Un module d’archivage fait son apparition, afin de générer des fichiers compressés après la compilation à partir d’une liste de fichiers à inclure. La propriété builtByDefault permet d’indiquer qu’un produit ne doit pas être compilé, à moins d’être explicitement demandé ; elle sert notamment à lancer des séries de test, comme la cible check de nombreux Makefile.

Source : qbs 1.4.0 released

Qt Creator 3.4.0

La nouvelle version de Qt Creator, numérotée 3.4.0, vient d’arriver. Elle se focalise sur le peaufinage de l’existant, avec des corrections de défauts (notamment au niveau du débogueur) et des améliorations du code interne, tout en apportant quelques nouvelles fonctionnalités.

Côté C++, une nouvelle action de refactorisation a été ajoutée pour déplacer les définitions de fonction en dehors d’une définition de classe ; également, l’autocomplétion propose maintenant la nouvelle syntaxe pour la connexion entre signaux et slots arrivée avec Qt 5. Un nouveau filtre propose également de signaler tous les fichiers C et C++ inclus dans le projet, même sans être explicitement mentionnés.

L’intégration Android est désormais compatible avec les chaînes de compilation 64 bits. Le développement sur des plateformes embarqués sans Qt (bare metal) peut être fait avec des projets génériques.

Clang se fait une place plus importante dans l’EDI : son analyseur statique n’est plus considéré comme expérimental, il peut d’ailleurs être utilisé en combinaison avec les compilateurs Visual C++ et MinGW.

Sources : Qt Creator 3.4.0 released, Qt Creator 3.4 RC1 released, Qt Creator 3.4 beta1 released.
Voir aussi : les notes de version.

PhysX sur GitHub : quelques nouveautés

Quelques nouveautés du côté de PhysX et de l’ouverture de son code (sans qu’on puisse parler de logiciel libre, toutefois). Le premier élément tient plus de l’ordre du détail : le dépôt GitHub précédent est déprécié au profit d’un dépôt par version majeure. PhysX-3.3 ne contiendra donc que PhysX 3.3 (et les diverses mises à jour, probablement), un nouveau dépôt sera créé pour la branche 3.4.

Ce nouveau dépôt contient maintenant les sources nécessaires à la compilation de PhysX pour iOS, ainsi que celles des exemples livrés avec le SDK. Plus intéressant : dans les semaines à venir, NVIDIDA proposera un contrat de licence pour les contributeurs. En conséquence, les développeurs de PhysX pourront recevoir et accepter des pull requests de la part d’utilisateurs de PhysX, ce qui ouvre le développement du moteur à un public plus large, tout comme Unreal Engine 4.

Source : New Github Repo: PhysX-3.3. Old repo PhysX is deprecated!

Qt Installer Framework 2.0

Le Qt Installer Framework est une brique logicielle prévue pour créer des installateurs, tant en ligne que hors ligne, pour Windows, Linux et OS X, en gérant les mises à jour. Bien que focalisé sur Qt, l’outil est suffisamment générique pour des applications ne l’utilisant pas.

La version 2.0 vient de sortir, avec quelques nouvelles fonctionnalités. La raison principale pour le changement de version majeure est que cet outil est maintenant compilé avec Qt 5 plutôt que Qt 4. La compatibilité a été préservée par rapport à la version précédente : il devrait être possible de mettre à jour une installation réalisée avec QIF 1.6 avec un installateur basé sur cette nouvelle version.

Notamment, le moteur JavaScript précédemment utilisé, Qt Script, a été remplacé par celui de Qt Quick, en gardant la compatibilité avec les scripts existants. Aussi, il devient possible de lancer des installations sans aucune interface graphique.

Télécharger Qt Installer Framework 2.0.
Voir aussi : les notes de version.
Source : Qt Installer Framework 2.0 Released