Sortie de LLVM 3.8

Publié le par
Répondre

Avec à peu près un mois de retard sur le planning, la nouvelle version de la suite de compilation LLVM est sortie, numérotée 3.8. Elle inclut notamment le compilateur C et C++ Clang. Quelques points sont mis en évidence par les développeurs :

  • OpenMP est maintenant activé par défaut dans Clang (la norme en version 3.1 était disponible en préversion dès Clang 3.7, le travail continue pour OpenMP 4.0 puis 4.5) ;
  • la compatibilité avec les autres compilateurs : une gestion des exceptions compatible avec les compilateurs Microsoft sous Windows, du TLS (une zone de mémoire privée pour chaque fil d’exécution pour des programmes parallèles à mémoire partagée) compatible avec GCC ;
  • la compilation de LLVM se fait maintenant de manière privilégiée avec CMake (plutôt que les autotools) ;
  • le tutoriel Kaleidoscope a été retravaillé pour faciliter l’utilisation de la plateforme LLVM par de nouveaux développeurs (notamment pour gérer d’autres langages en entrée) ;
  • LLVM ne garantit plus la compatibilité avec les versions les plus anciennes de Windows, c’est-à-dire antérieures à Windows 7.

Calcul de haute performance

Pour le calcul de haute performance, cette nouvelle version apporte bien des nouveautés intéressantes. Un certain nombre de fonctionnalités d’OpenCL 2.0 est implémenté, notamment au niveau de la gestion des espaces d’adressage ou encore des types atomiques (compatibles avec ceux définis par C11) et d’images (des tableaux bidimensionnels, comme image2d_depth_t ou image2d_array_depth_t).

Du côté d’OpenMP, la version 3.1 de la norme est maintenant entièrement supportée. À l’exécution, ce ne sera plus la bibliothèque GCC OpenMP qui sera utilisée, mais bien celle de Clang, développée par Intel (et développée à partir de celle utilisée pour leurs compilateurs propriétaires). Le développement continue pour OpenMP 4.0 et 4.5, avec notamment les clauses map, num_teams et thread_limit ou encore les dépendances entre tâches.

Pour CUDA, la technologie propriétaire de calcul sur processeurs graphiques de NVIDIA, les fonctionnalités arrivent petit à petit (elles sont toujours considérées comme expérimentales). Le code de Google n’est toujours pas intégré à Clang, mais il peut maintenant s’interfacer avec cette version sans modification spécifique.

Source : [llvm-announce] LLVM 3.8 Release, Clang 3.8 Release Notes

Qt 5.7 Alpha

Publié le par
Répondre

La première préversion de Qt 5.7 pointe le bout de son nez, peu de temps après Qt 5.6 RC. À cause de retards du côté de Qt 5.6, les deux versions ont été développées en parallèle : quand Qt 5.6 se focalisait sur la stabilisation, Qt 5.7 s’enrichissait en fonctionnalités.

Parmi les nouveautés, la compatibilité avec C++98 ne sera plus nécessaire, ouvrant des perspectives avec C++11 ; les Qt Quick Controls verront leur deuxième version, plus optimisée pour les plateformes embarquées ; Qt 3D sera disponible en version finale ; Qt SerialBus gérera les communications par bus série. L’évolution se fera aussi au niveau des licences, allant de pair avec la libération d’une série de modules précédemment uniquement disponibles dans les éditions commerciales : Qt Chart, Qt Data Visualization, Qt Purchasing, Qt Virtual Keyboard et Qt Quick 2D Renderer.

Source : Qt 5.7 Alpha Released

Un premier pilote pour Vulkan

Publié le par
Répondre

NVIDIA vient de rendre disponible ses pilotes en version 364.47, après la 362 la semaine dernière. Cet incrément dans les numéros de version n’est pas si fréquent de leur part, mais il n’indique pas pour autant que cette nouvelle version ait été publiée en toute hâte : elle inclut des améliorations de performance pour une série de jeux (Tom Clancy’s The Division, Need for Speed, pour leur sortie récente ; Hitman, Ashes of the Singularity, Rise of the Tomb Raider) et la gestion du SLI pour d’autres (Hitman, The Technomancer, Zui Shong Bing Qi), en cours de développement depuis plus longtemps, quand la version précédente se focalisait sur la sortie de Far Cry Primal.

Le point le plus important de cette version concerne Vulkan : NVIDIA est le premier à fournir un pilote compatible Vulkan au grand public. Des préversions régulièrement modifiées étaient déjà disponibles depuis l’annonce de la norme, mais ces pilotes étaient prévus pour les développeurs principalement et étaient basés sur une plus vieille branche de développement (la 355, sortie en août 2015). A contrario, Intel propose des pilotes libres pour Linux, parfaitement conformes à la norme mais à compiler soi-même, rien pour Windows ; AMD propose une préversion de pilotes pour Windows.

Qt Virtual Keyboard : nouveautés pour Qt 5.6 et 5.7

Publié le par
Répondre

Pour sa première version libre, Qt Virtual Keyboard vient avec un nouveau pan de fonctionnalités : la reconnaissance d’écriture. Jusqu’il y a peu entièrement commercial, ce composant est maintenant disponible sous licence GPLv3. Il ne sera pas disponible avec toutes les éditions de Qt 5.6 (il devra être téléchargé et compilé séparément), mais il sera bien intégré dès Qt 5.7 comme n’importe quel autre module d’extension.

Ce module contient un clavier virtuel, principalement à destination des écrans tactiles dans des applications dépourvues de clavier physique (comme sur téléphone ou bon nombre d’applications embarquées). Il est principalement prévu pour être utilisé en QML et peut être étendu à de nouvelles langues ou disposition facilement.

Reconnaissance d’écriture

Qt Virtual Keyboard peut utiliser deux moteurs pour ses nouvelles fonctionnalités de reconnaissance d’écriture : Lipi, un logiciel libre, ou T9 Write, son pendant commercial. Le premier a été intégré dans les sources du composant, il a également été optimisé, principalement à cause de sa performance inadéquate pour les plateformes embarquées (il a d’abord été prévu pour des téléphones Android). Les étapes de reconnaissance et de chargement des modèles ont été accélérées de dix à quarante pour cent, ce qui le rend plus compétitif par rapport à la concurrence commerciale.

L’utilisateur peut dessiner ses caractères partout sur l’écran, pas seulement dans la zone réservée au clavier, à l’aide d’un double clic dans cette zone — ce qui a pour impact de cacher le clavier.

Chinois traditionnel

L’autre grande modification par rapport aux versions précédentes concerne l’entrée de texte en chinois traditionnel, un jeu d’idéogrammes utilisé dans certaines régions comme Hong Kong ou Taïwan, avec trois méthodes d’entrée : pinyin (qui correspond au chinois simplifié, utilisé en Chine continentale, avec une translittération dans l’alphabet latin), cangjie (qui exploite l’étymologie des idéogrammes) et zhuyin (qui utilise un alphabet phonétique).

Clavier pinyin

Clavier cangjie

Clavier zhuyin

Source (dont images) : Qt Virtual Keyboard Updated with Handwriting Recognition

Compression : zlib obsolète ?

Publié le par
Répondre

zlib est une bibliothèque de compression très largement utilisée dans bon nombre d’applications : les consoles de jeu les plus récentes (Playstation 3 et 4, Xbox 360 et One, notamment), mais aussi le noyau Linux, les systèmes de gestion des versions comme SVN ou Git ou le format d’image PNG. Sa première version publique a été publiée en 1995 par Jean-Loup Gailly et Mark Adler en implémentant la technique DEFLATE. Son succès est notamment dû à l’absence de brevets logiciels (ce qui a principalement un intérêt aux États-Unis) sur ses algorithmes, mais aussi à des débits en compression et décompression relativement élevés pour une utilisation en ressources assez faible et un bon taux de compression.

Fonctionnement de zlib

Au niveau algorithmique, DEFLATE utilise des techniques éprouvées des années 1990, principalement un dictionnaire (selon l’algorithme LZ77) et un codage de Huffman. Le principe d’un dictionnaire est de trouver des séquences de mots répétées dans le fichier à compresser et de les remplacer par un index dans un dictionnaire. Le codage de Huffman fonctionne avec un arbre pour associer des codes courts à des séquences de bits très fréquentes. Ces deux techniques s’associent pour former la technique de compression standard actuelle.

Concurrents modernes

Cependant, depuis le développement de ces techniques, la recherche au niveau de la compression sans perte a fait de grands progrès. Par exemple, LZMA (l’algorithme derrière 7-Zip et XZ) exploite des idées similaires (plus la probabilité de retrouver des suites de bits dans le fichier à compresser, plus la manière compressée de l’écrire doit être courte), mais avec une dépendance entre différentes séquences de bits (chaîne de Markov), ainsi qu’un codage arithmétique. Le résultat est un taux de compression souvent bien meilleur que DEFLATE, mais le processus de compression est bien plus lent, tout en gardant une décompression rapide et sans besoins extravagants en mémoire. LZHAM est aussi basé sur les mêmes principes avec des améliorations plus modernes et vise principalement une bonne vitesse de décompression (au détriment de la compression).

Cependant, pour un usage plus courant, les débits en compression et décompression sont aussi importants l’un que l’autre, avec un aussi bon taux de compression que possible. Par exemple, pour des pages Web d’un site dynamique, le serveur doit compresser chaque page indépendamment, puisque le contenu varie d’un utilisateur à l’autre. Plusieurs bibliothèques de compression sont en lice, comme LZ4 (qui se propose comme une bibliothèque très généraliste, comme zlib, mais très rapide en compression et décompression), Brotli (proposé par Google pour un usage sur le Web) ou encore BitKnit (proposé par RAD pour la compression de paquets réseau — cette bibliothèque est la seule non libre dans cette courte liste). Ces deux dernières se distinguent par leur âge : elles ont toutes deux été annoncées en janvier 2016, ce qui est très récent.

Une première comparaison concerne la quantité de code de chacune de ces bibliothèques : avec les années, zlib a accumulé pas loin de vingt-cinq mille lignes de code (dont trois mille en assembleur), largement dépassé par Brotli (pas loin de cinquante mille lignes, dont une bonne partie de tables précalculées). Les deux derniers, en comparaison, sont très petits : trois mille lignes pour LZ4 ou deux mille sept cents pour BitKnit (en incluant les commentaires, contrairement aux autres !).

Tentative de comparaison

Rich Geldreich, spécialiste de la compression sans perte et développeur de LZHAM, propose une méthodologie pour comparer ces bibliothèques : au lieu d’utiliser un jeu de données standard mais sans grande variété (comme un extrait de Wikipedia, c’est-à-dire du texte en anglais sous la forme de XML), il propose un corpus de plusieurs milliers de fichiers (ce qui n’a rien de nouveau, Squash procédant de la même manière) et présente les résultats de manière graphique. Cette visualisation donne un autre aperçu des différentes bibliothèques.

Ce graphique montre, sur l’axe horizontal (logarithmique), les débits en décompression (plus un point est à droite, plus la décompression est rapide) et, sur l’axe vertical (logarithmique aussi), le taux de compression (plus il est élevé, plus le fichier a été réduit en taille). Chaque couleur correspond à un algorithme : vert pour zlib, noir pour LZHAM, rouge pour Brotli, bleu pour BitKnit et jaune pour LZ4.

Deux nuages de points sortent du lot : LZ4, tout à droite, est extrêmement rapide en décompression, tout l’opposé de LZHAM, qui propose néanmoins de bien meilleurs taux de compression. zlib montre un comportement assez étrange : le débit de décompression n’augmente plus à partir d’un certain point, contrairement aux autres bibliothèques. L’auteur propose des comparaisons plus spécifiques des taux de compression de chaque bibliothèque en fonction des fichiers.

Et donc ?

Cette comparaison montre que les différentes bibliothèques ne sont pas toujours meilleures les unes que les autres, tout dépend du contenu du fichier, de sa taille, des ressemblances par rapport aux estimations des concepteurs (plus particulièrement dans le cas d’algorithmes qui ne s’adaptent pas dynamiquement au contenu et préfèrent utiliser des tables prédéfinies, ce qui évite de transmettre une série d’informations).

Notamment, Brotli est prévu pour le Web : il fonctionne particulièrement bien sur des données textuelles. Tout comme zlib, il utilise des tables précalculées, ce qui lui donne un avantage sur des fichiers plus petits. Au contraire, BitKnit fonctionne très bien sur du contenu binaire, bien plus courant pour les données de jeux vidéo. Ces deux bibliothèques ont donc chacune leurs points forts selon les domaines d’application prévus et y sont meilleures que zlib.

Sources : zlib in serious danger of becoming obsolete.

NVIDIA GameWorks, des annonces à venir en 2016, notamment DirectX 12

Publié le par
Répondre

L’objectif du programme GameWorks de NVIDIA est de fournir une série d’effets graphiques facilement intégrables à des jeux, mais aussi divers outils pour faciliter leur développement : par exemple, des effets de débris utilisés dans Fallout 4, une simulation de cheveux et poils très utilisée, des optimisations de rendu pour la réalité virtuelle intégrées dans Unreal Engine 4. Le moteur physique PhysX fait également partie du programme GameWorks, largement plébiscité : actuellement, pas moins de cent cinquante mille personnes sont inscrites à ce programme, téléchargeant principalement Nsight, Androidworks, PhysX, FleX et HairWorks. Le contenu de GameWorks n’est pas réservé aux développeurs professionnels, les bibliothèques sont également accessibles aux particuliers qui développent des jeux ou des animations dans leur temps libre (comme celle ci-dessous).

NVIDIA GameWorks : depuis les premiers effets

L’affaire GameWorks a commencé sous ce nom en 2013 pour officialiser une équipe qui travaillait depuis le début des années 2000 directement avec les développeurs de jeux : elle cherchait à améliorer leur rendu et optimiser leur performance, pour développer le plein potentiel des processeurs graphiques. Leurs communications passaient par des articles publiés lors du SIGGRAPH (une grande conférence pour l’animation par ordinateur), des codes d’exemple ou encore des démonstration purement technologiques.

Ces efforts ont payé, mais n’étaient pas suffisants : une leçon de cette longue période informelle est qu’une technologie n’est jamais prête avant d’avoir été intégrée complètement dans un jeu. Tel est l’objectif de GameWorks : rassembler des techniques éprouvées dans au moins un jeu et en faciliter l’adoption. Cela signifie aussi s’assurer que l’effet visuel est disponible au plus grand nombre, pas seulement à ceux qui disposent de matériel de dernière génération.

Une attention pour les développeurs de jeux

Un autre problème, en passant d’exemples de code à des bibliothèques complètes, est le besoin d’acceptation de la part des développeurs : les bibliothèques GameWorks sont prévues pour être simples à intégrer (et le sont déjà pour une série de moteurs de jeux)… mais ne viennent pas directement avec le code source. Ce mode de fonctionnement convient très bien à certains développeurs, alors que d’autres ont besoin de mettre les mains dans le cambouis : au fil du temps, ces bibliothèques ont été adaptées pour laisser une plus grande flexibilité au développeur et en distribuant les sources à la demande.

Pour le moment, les composants de GameWorks sont principalement disponibles pour Windows, plus spécifiquement DirectX 11. En effet, cette version est la plus utilisée pour les jeux actuels et ne limite pas le développement des effets (plus particulièrement ceux qui exploitent la physique). Cependant, DirectX 12 gagne du terrain du côté des jeux et les bibliothèques GameWorks verront des versions compatibles avec cette nouvelle version, selon la demande des développeurs de jeux.

Bien que rien ne soit actuellement prêt pour annonce, selon les gens de NVIDIA, pas mal d’annonces auront lieu en 2016, entre GameWorks et DirectX 12. Elles suivront une année 2015 relativement chargée, avec l’inclusion de technologies dans des jeux comme Fallout 4 ou The Witcher 3, mais aussi la première inclusion de WaveWorks pour la simulation d’océans dans Just Cause 3 et War Thunder. Sans oublier les controverses.

Source : Nvidia Talks GameWorks And DirectX 12 Plans For 2016.

Build2 : une chaîne de compilation et de distribution de code C++

Publié le par
Répondre

Build2 a vu sa première version sortir ce mois-ci. Cet outil C++ est prévu comme une chaîne de compilation, un gestionnaire de paquets et une interface en ligne, principalement pour le monde C++ (même si les autres langages ne sont pas mis en avant, l’outil pourra les gérer). Il gère le même genre de problèmes que Conan : pour utiliser une nouvelle bibliothèque en C++, il faut gérer la compilation (qui peut varier fortement d’une plateforme à l’autre, d’un compilateur à l’autre) et les dépendances éventuelles, qui à leur tour viennent avec leurs particularités. Build2 propose ainsi une nouvelle syntaxe pour gérer les fichiers dictant le mode opératoire pour la compilation, comparable à make et CMake.

Concrètement, le projet est divisé en plusieurs morceaux : build2 pour le système de compilation, bpkg pour le gestionnaire de paquets et brep pour l’interface Web. Ce dernier est déjà à l’Å“uvre sur cppget.org, que les développeurs espèrent voir devenir la plateforme de référence pour les bibliothèques C++ (même s’il ne contient, à ce jour, que quelques paquets, tous issus de Build2).

bpkg est le point central pour tout utilisateur : il sert à créer un nouveau projet, à ajouter des dépôts pour la gestion des dépendances, puis à la compilation et à la gestion de la mise à jour de ces dépendances. Ensuite, le pilote b s’occupe de la compilation de tout projet C++, une fois les dépendances installées. Ainsi, la manière la plus courante de l’utiliser est d’utiliser ces commandes, de la création du projet à sa compilation, en passant par les dépendances :

$ bpkg create cxx config.cxx=clang++
created new configuration in ./

$ bpkg add https://pkg.cppget.org/1/alpha
added repository cppget.org/alpha

$ bpkg fetch
fetching cppget.org/alpha
fetching cppget.org/beta (complements cppget.org/alpha)
[...]
10 package(s) in 4 repository(s)

$ bpkg build bpkg
build libbutl 0.2.0 (required by bpkg libbpkg)
build libbpkg 0.2.0 (required by bpkg)
build bpkg 0.2.0
continue? [Y/n] y
[...]
bpkg-0.2.0.tar.gz             100% of  144 kB  130 kBps 00m01s
fetched bpkg 0.2.0
unpacked bpkg 0.2.0
configured bpkg 0.2.0
c++ bpkg-0.2.0/bpkg/cxx{bpkg}
[...]
ld bpkg-0.2.0/bpkg/exe{bpkg}

$ b -v
g++-5 -I/tmp/hello-gcc5-release/libhello-1.0.0+1 -O3 -std=c++11 -o hello.o -c ../hello2/hello.cpp
g++-5 -O3 -std=c++11 -o hello hello.o /tmp/hello-gcc5-release/libhello-1.0.0+1/hello/libhello.so

Pour le moment, le projet est décrit comme une préversion technologique, rien n’est véritablement fixé dans le marbre. Il est porté par la société Code Synthesis, qui ne s’oriente pas complètement autour de ce gestionnaire de dépendances : contrairement au prédécesseur de Conan, Biicode, la viabilité de ce nouvel écosystème ne dépendra pas uniquement du modèle économique développé pour lui, ce qui pourrait en augmenter les chances de survie.

Site de Build2.

Fedora et GCC 6 montrent de mauvaises pratiques de codage

Publié le par
Répondre

Pour leur version 24, les développeurs de la distribution Linux Fedora ont notamment voulu utiliser la dernière version du compilateur GCC, qui sera la GCC 6.1 quand la nouvelle version de la distribution sera disponible (GCC 6 est prévu pour avril 2016, Fedora 24 vers juin). Ainsi, cette semaine, les développeurs ont lancé une compilation complète de l’entièreté des paquets de Fedora, en préparation de ce changement de compilateur.

Leur processus était le suivant : d’abord tenter une compilation de tous les 17 741 paquets avec GCC 6, puis, pour ceux dont la compilation a échoué, retenter la compilation avec GCC 5. Si la compilation échoue deux fois, le problème vient du paquet, sinon de GCC. Un peu moins de mille paquets ont ainsi échoué deux fois, ce qui en laisse à peu près six cents qui ont échoué avec GCC 6 mais pas GCC 5. En comparaison, pour le passage de GCC 4.9 à GCC 5, moins de la moitié avait posé problème. La nouvelle version de GCC serait-elle si mauvaise ?

Effectivement, une série de ces problèmes était due à des régressions au niveau de GCC, des défauts qui ont rapidement été corrigés en vue de la sortie de la version finale. La majorité des cas, cependant, vient des développeurs des applications concernées. Pour une série d’entre eux, le problème vient du fait que GCC 6 compilera le code C++ par défaut en mode C++14 (au lieu de C++98, une norme bien dépassée) : ces paquets n’étaient pas prêts et ont dû être recompilés avec GCC 5.

Pour d’autres, certains changements dans l’implémentation de la bibliothèque standard C++ et, surtout, de nouveaux messages d’erreur ont montré des pratiques de programmation douteuses dans le chef des développeurs des applications disponibles dans Fedora. Les réponses des développeurs de GCC sont parfois éloquentes quant à ces mauvaises pratiques :

The code is nonsense, what’s it even supposed to do? […] It’s useless, and only compiled by accident.

Allowing it with -fpermissive might make sense though, as that flag allows all kinds of terrible rubbish to compile.

Les mêmes défauts seront probablement remarqués par les autres distributions en passant à GCC 6, comme Gentoo, habituellement prompte à se mettre à jour.

Source : Fedora mass rebuild 2016.

Qt en 2016

Publié le par
Répondre

L’année 2016 promet sa dose d’actualité Qt, avec trois versions qui devraient voir le jour : Qt 5.6 en mars, Qt 5.7 en mai et Qt 5.8 en octobre. De manière générale, Qt vise une haute qualité sur toutes les plateformes gérées (qu’elles soient plus ou moins mobiles) tout en limitant le temps de mise sur le marché pour ses utilisateurs. C’est pourquoi Qt 5.6 a été retardé : cette version aurait dû voir le jour en décembre dernier. Le cÅ“ur de Qt n’est pas très spécifique à un environnement ou l’autre, même si un bon nombre de fonctionnalités plus orientées vers l’une ou l’autre industrie en particulier : par exemple, les débats ont récemment tourné autour du protocole CAN, prévu pour la communication entre microcontrôleurs dans l’automobile ; l’implémentation a mené à un module Qt SerialBus, qui est bien plus général que le type de bus visé au départ, l’API pouvant alors être généralisée à d’autres types de bus en série, comme Modbus ou OPC-UA.

Qt 5.6 : première version avec support à long terme

Qt 4.8 est sorti en 2013, mais a été maintenu pendant plusieurs années, alors qu’une version de Qt normale ne l’est que pendant quelques mois. Il n’y avait pas encore eu de version avec un support à long terme dans la branche Qt 5 et cela arrivera avec Qt 5.6. Par rapport à Qt 4.8, les améliorations sont très nombreuses, avec notamment une accélération matérielle pour l’affichage, peu importe la technologie employée ; Qt Quick y voit sa deuxième version majeure, avec une plus grande maturité ; les plateformes mobiles sont mieux gérées.

Qt 5.6 aura droit à du support pendant trois ans à compter de sa date de sortie, c’est-à-dire jusqu’en 2019. Les nouveautés des versions de Qt qui suivront ne seront pas réintégrées, à l’exception des corrections de défauts, notamment de sécurité. Pour son développement, Qt 5.6 a vu les efforts converger vers une amélioration générale de la qualité du code et la parité entre plateformes au niveau des fonctionnalités. Cette version avec support à long terme permettra de limiter en partie la rétrocompatibilité pour les versions à venir : Qt se tournera vers C++11, sans plus chercher à être compatible avec les plus vieux compilateurs et la norme C++98.

La fonctionnalité phare de Qt 5.6 sera la gestion des écrans à haute résolution, un mouvement initié par Apple avec ses écrans Retina. Qt ajustera automatiquement son affichage à la résolution de l’écran : taille de police, icônes, graphiques, etc. Surtout, les applications s’ajusteront automatiquement lors du passage d’un écran à un autre possédant une résolution plus élevée, chose traditionnellement mal gérée par les applications.

Qt 5.7 : des modules en tout sens

Puisque Qt 5.6 sera là pour les compilateurs les plus anciens, Qt 5.7 pourra s’orienter définitivement vers C++11 : là où il n’était pas impossible d’utiliser certaines nouvelles fonctionnalités du langage dans Qt (comme la connexion de signaux à des fonctions anonymes), Qt 5.7 pourra utiliser C++11 directement dans l’implémentation de ses modules, nouveaux ou plus anciens, sans contrainte particulière. Le module Qt SerialBus sera le premier à profiter de ce traitement de faveur.

Qt 5.7 arrivera avec une pléthore de nouvelles fonctionnalités, changements qui viennent en parallèle avec une évolution des licences. Tout d’abord, trois modules quitteront le statut de préversion technologique (sans support officiel, donc) :

  • Qt Quick Controls 2, un ensemble de composants Qt Quick réécrits et optimisés ;
  • Qt 3D, un moteur 3D multifil pour Qt en C++ et Qt Quick ;
  • Qt SerialBus, un système de communication par bus série depuis une application Qt, actuellement pour CAN et Modbus.

Ensuite, plusieurs modules seront libérés : ils étaient disponibles exclusivement sous licence commerciale, ils seront disponibles dans l’édition libre. Ces modules sont au nombre de cinq :

  • Qt Charts, pour la visualisation en 2D de données ;
  • Qt Data Visualization, pour la visualisation en 3D de données ;
  • Qt Purchasing, une API multiplateforme pour gérer les achats depuis les différentes boutiques en ligne pour chaque plateforme ;
  • Qt Virtual Keyboard, un clavier virtuel adaptable, gérant plusieurs langues et la reconnaissance d’écriture ;
  • Qt Quick 2D Renderer, un moteur d’affichage pour les applications Qt Quick 2 sans accélération OpenGL.

Finalement, deux nouveaux modules feront leur apparition en qualité de préversion technologique : Qt Wayland Compositor et Qt SCXML, qui généralise les fonctionnalités de machines d’états.

Qt 5.8 : plus modulaire, plus optimisé, plus Vulkan

Qt 5.8 devrait arriver fin de cette année. Quand Qt 5.7 apportera bon nombre de fonctionnalités plus incrémentales, Qt 5.8 retournera au niveau des fondations pour préparer le futur, des changements qui continueront dans les versions futures et qui s’inscrivent dans la lignée de Qt 5.0 (une modularisation accrue, une utilisation d’OpenGL pour tout l’affichage). Un des points sera l’optimisation de l’utilisation de la mémoire, rapidement problématique dans l’embarqué.

Qt 5.0 est venu avec une architecture bien plus modulaire qu’auparavant, avec une série de modules formant le cÅ“ur de Qt et des ajouts : il n’est pas nécessaire d’inclure tous les modules dans une application (contrairement à Qt 3), avec une séparation plus claire que du temps de Qt 4. Par contre, les interdépendances entre modules sont toujours fortes : il est parfois nécessaire d’inclure un module pas très utile pour bénéficier de fonctionnalités dans un autre, ce qui est rapidement problématique dans les applications embarquées, par définition limitées, y compris au niveau du stockage. L’objectif est de créer une configuration minimale pour Qt Quick pour limiter le nombre de dépendances, ce qui impliquera des changements au moins dans les modules Qt Core, Qt GUI et Qt Declarative.

KDAB et la Qt Company sont membres de Khronos, le consortium qui se charge de la spécification de normes comme OpenGL ou Vulkan. Ce n’est pas un hasard : Qt 5.8 devrait retirer la dépendance directe envers OpenGL au niveau du graphe de scène, qui devrait être remplacée par une abstraction permettant de choisir entre différentes API. Les premiers pas devraient venir avec Qt 5.8, avec à terme l’utilisation des dernières API graphiques disponibles sur chaque plateforme — et la suppression d’ANGLE côté Windows (une implémentation d’OpenGL utilisant DirectX).

Finalement, une dernière technologie anciennement propriétaire devrait être libérée : le Qt Quick Compiler. Il ne sera plus disponible sous la forme de module séparé, mais bien directement dans Qt Declarative, pour compiler en code natif les interfaces Qt Quick. Les objectifs sont multiples : améliorer fortement la performance sur les plateformes qui ne peuvent pas bénéficier de technologies JIT (iOS et Windows RT), mais aussi diminuer les temps de démarrage des applications.

Qt Creator 4.0 : une apparence plus moderne, plus de Clang, plus de CMake

Une nouvelle version majeure de Qt Creator, l’EDI Qt, fera également son apparition, normalement en avril. Tout comme Qt, une série de fonctionnalités transitera de l’édition commerciale vers la version libre, comme un profilage avancé, un analyseur statique de code ou encore un éditeur visuel Qt Quick bien plus poussé. L’interface sera rafraîchie avec de nouvelles icônes, plus modernes. L’interface des extensions sera également revisitée ; Clang sera de plus en plus utilisé, lui qui arrive petit à petit dans l’éditeur depuis plusieurs versions. Également, CMake sera mieux géré dans l’éditeur.

Source : Qt Roadmap for 2016.

Qt rejoint le consortium Khronos

Publié le par
Répondre

La Qt Company, la filiale de Digia qui produit Qt, a rejoint le consortium Khronos, qui regroupe bon nombre d’industriels de l’informatique pour le développement en commun de normes, la plus connue étant sans doute OpenGL. De manière générale, le groupe Khronos développe des normes pour le calcul parallèle (OpenCL), les graphismes (OpenGL et maintenant Vulkan), y compris pour le Web (WebGL), la vision par ordinateur (OpenVX) et bien d’autres.

La norme Khronos la plus utilisée dans Qt est bien sûr OpenGL, en tant qu’interface de relativement bas niveau pour accéder à la carte graphique. Qt a longtemps permis d’accéder facilement à cette API pour faciliter le développement d’applications 3D et, depuis Qt 5.0, l’utilise même de manière préférentielle pour tout l’affichage, ce qui permet d’exploiter au mieux le matériel actuel pour tout type d’interface (y compris en 2D). Depuis peu, Qt donne aussi accès à WebGL à travers le module Qt Canvas 3D pour intégrer du contenu 3D dans des interfaces Qt Quick.

L’objectif de la Qt Company est bien sûr de participer au développement de nouvelles versions des normes de Khronos, en particulier OpenGL et Vulkan. Pour le moment, les plans dévoilés sont de fournir un accès aux API Vulkan « les plus pertinentes » pour Qt. Les premiers résultats ne devraient pas tomber avant Qt 5.8, en fin d’année (puisque Qt 5.7 est déjà en cours de stabilisation). La migration du cÅ“ur de Qt d’OpenGL vers Vulkan ne devrait pas arriver rapidement, étant donné que ce choix limiterait le caractère multiplateforme de Qt (Apple n’envisage pas d’implémenter Vulkan, lui préférant son API propriétaire Metal), même si cela pourrait apporter quelques gains en performance (bien que pas forcément suffisants pour justifier l’investissement en temps).

La Qt Company rejoint ainsi KDAB, autre grand contributeur à Qt et membre de Khronos depuis l’année dernière. Entre Qt et la 3D, KDAB est bien connu pour le développement de Qt3D, un moteur 3D complet qui arrive prochainement dans Qt (des préversions technologiques sont d’ores et déjà disponibles dès Qt 5.5, améliorées pour Qt 5.6).

Source : The Qt Company joins Khronos Group and promotes Vulkan.