Sortie d’Unreal Engine 4.13

Publié le par
Répondre

L’Unreal Engine nouveau est arrivé, trois mois après le précédent, comme d’habitude. Là où la version précédente se concentrait sur la réalité virtuelle, la version 4.13 s’éparpille plus, même si l’éditeur en réalité virtuelle est toujours l’objet d’une grande attention. Parmi les domaines d’améliorations, on compte cette fois le rendu et l’éditeur de cinématiques, même s’il est impossible de citer toutes les nouveautés en peu de mots.

Éditeur de cinématiques Sequencer

L’éditeur non linéaire de cinématiques apparu dans la 4.12 reste le théâtre d’opérations d’envergure, avec la possibilité d’enregistrer en direct une partie dans le jeu développé. Cette capture n’est pas une vidéo : au contraire, toutes les animations, tous les effets, tous les sons sont mémorisés séparément et peuvent être modifiés dans l’éditeur ! Au moment de cette capture, il est aussi possible de limiter l’enregistrement à une série de composants et de propriétés.

Rendu

Du côté du rendu 3D, les lampes ont vu leur code optimisé : si une lumière ne se déplace pas dans la scène, une bonne partie des calculs déjà effectués peuvent être réutilisés sans problème pour la prochaine image à afficher. Le problème de performance vient surtout du calcul des ombres que crée la lumière (plus précisément, de la carte des profondeurs). Cette optimisation est appliquée automatiquement et ses résultats sont intéressants : pour afficher l’image ci-dessous, avec trente-trois points de lumière, il faut compter 14,89 ms pour l’affichage des ombres ; grâce aux caches implémentés, la même partie prend 0,9 ms d’affichage, ce qui permet d’ajouter d’autres effets (il faut cependant compter deux millisecondes pour l’affichage de la lumière, une contribution qui n’est pas touchée par cette optimisation).

Unreal Engine permet de générer des matériaux de manière aléatoire grâce à des fonctions de bruit. La famille d’algorithmes disponibles s’est agrandie pour recevoir le bruit de Voronoï, très souvent utilisé pour la génération procédurale. Il s’applique notamment très bien à la génération de marbre, le rendu étant très réaliste après un peu de configuration.

Il devient possible de superposer des couches de matériaux sur une topologie statique, ce qui peut avoir un effet de lissage entre les différents calques, sans utiliser de projection.

L’interaction avec des composants d’interface graphique intégrés dans le monde peut se faire avec n’importe quel pointeur laser (pas simplement directement avec la souris). L’action ainsi générée simule celle que pourrait avoir un composant matériel : un clic gauche ou droit… ou toute autre interaction. Cette amélioration vient en support à celles de l’éditeur en réalité virtuelle (voir plus bas).

Les applications mobiles pourront utiliser des effets de type posttraitement, par exemple comme si l’image venait d’une vieille télévision. Ces effets ne peuvent pas encore exploiter toutes les informations disponibles pour le rendu (la profondeur de chaque pixel n’est pas encore accessible), mais cela devrait venir avec une version ultérieure. Ces effets ne sont pas disponibles sur les versions les plus ancestrales d’Android.

Les opérations de pavage des paysages sont maintenant bien plus rapides qu’avant, l’accélération matérielle étant mieux utilisée : cette technique de rendu n’est utilisée que pour les plus hauts niveaux de détail, elle ne l’est plus du tout pour les plus faibles (comme des zones lointaines).

Éditeur en réalité virtuelle

Le nouvel éditeur en réalité virtuelle, apparu pour la 4.12, est toujours l’objet d’une grande attention. Il devient possible de peindre sur des textures existantes, par exemple.

Il permet aussi de peindre rapidement une série d’arbres, en sélectionnant simplement le type de feuillage à créer.

 

Bien évidemment, cette nouvelle version vient avec bien d’autres nouvelles fonctionnalités et optimisations, décrites dans les notes de version.

Source et images : UNREAL ENGINE 4.13 RELEASED!.

Des nouveautés du côté de la compression

Publié le par
Répondre

Au niveau algorithmique, la compression de données sans perte (à la ZIP, RAR, TAR.GZ, 7Z) n’a plus beaucoup évolué ces dernières années : il s’agit toujours d’un assemblage de dictionnaires, de code de Huffman, de codage arithmétique, de modèle statistique. Il n’empêche : ces techniques, bien maîtrisées, peuvent toujours s’améliorer petit à petit et donner des outils de compression redoutablement efficaces, comme Google Brotli, arrivé sur le marché début 2016.

Bien maîtrisées, ces techniques peuvent… faire d’énormes progrès ! C’est ainsi que RAD Games a annoncé de nouveaux outils de compression (propriétaires et payants) qui fonctionnent nettement mieux que la concurrence (principalement libre), en fonction du critère de comparaison. Au niveau de l’implémentation, rien de vraiment neuf, si ce n’est un soin tout particulier apporté par de fins connaisseurs du domaine de la compression, avec et sans pertes.

La société peut maintenant se targuer de proposer un outil de compression dont la principale caractéristique est une décompression extrêmement rapide (de trois à cinq fois plus que zlib) avec des taux de compression du même ordre que LZMA (en étant dix à trente fois plus rapide que ce dernier), nommé Kraken. Il donne aussi du fil à retordre à LZ4 : ce dernier reste le plus rapide sur tous les types de documents, mais Kraken s’en rapproche fortement tout en gardant une compression nettement meilleure que LZ4.

Deux dérivés (disponibles depuis cet été) de cet outil sont plus spécialisés, en compressant moins mais en décompressant (beaucoup) plus vite : Mermaid offre une compression moyenne (du même ordre que ZIP), tout en étant extrêmement rapide en décompression (de sept à douze fois plus que zlib, c’est-à-dire plus de deux fois plus rapide que Kraken) ; Selkie, au contraire, abandonne encore un peu de compression (entre ZIP et LZ4), pour dépasser LZ4 d’un facteur de presque deux (la décompression est très proche d’une copie en mémoire, ce qui est un tour de force technique pour une compression non triviale).

Les chiffres du terrain

Les chiffres donnés sont les officiels, reste encore à les confirmer par des extérieurs. Les comparaisons parfaitement équitables sont difficiles à obtenir, puisque les outils de compression ne sont pas si faciles à obtenir.

En comparant le ratio de compression avec les débits, ces trois outils sont collés du côté des hauts débits (même si Kraken n’y est que peu présent). Zlib occupe une place intermédiaire.

Ces algorithmes sont moins optimisés en temps pour la compression, il n’empêche qu’ils présentent de bons résultats. Ils sont nettement plus éloignés de leurs meilleurs concurrents (comme LZ4… ou zlib).

Du côté algorithmique ?

Ces outils étant propriétaires, difficile d’aller lire leur code source pour comprendre les améliorations proposées. Cependant, certains s’avancent et proposent des pistes qui auraient permis d’atteindre ces nouveaux sommets. Le décodage très rapide pourrait venir d’une utilisation très judicieuse de la hiérarchie mémoire des processeurs actuels : autant de données que possible sont stockées dans les caches du processeur afin de limiter les accès à la mémoire vive (qui sont extrêmement lents).

Une tout autre piste suit la théorie des langages formels, en tentant de construire une grammaire dont le seul mot accepté est le fichier à compresser : les promesses de l’algorithme GLZ sont d’atteindre des taux de compression dignes des algorithmes de prédiction par reconnaissance partielle (la probabilité de rencontrer un symbole — par exemple, un octet — dépend d’un certain nombre de symboles déjà lus) tout en gardant la rapidité des algorithmes de la famille LZ (qui fonctionnent avec des dictionnaires). Les grammaires ainsi générées ont pour particularité d’avoir une entropie faible, c’est-à-dire qu’elles se compressent très bien par d’autres algorithmes.

Toutefois, il semblerait que ces pistes n’aient pas été suivies pour le développement de ces algorithmes. Peut-être nourriront-elles la prochaine génération d’outils de compression ? Cependant, les compromis subsisteront probablement : la révolution d’un algorithme qui compresse très vite et très bien et qui décompresse au moins aussi vite n’est pas encore en vue.

Sources : site officiel d’Oodle, nouveautés d’Oodle 2.3.0 (dont images), Kraken compressor , Grammatical Ziv-Lempel Compression: Achieving PPM-Class Text Compression Ratios With LZ-Class Decompression Speed, RAD’s ground breaking lossless compression product benchmarked (dont images).
Voir aussi : le blog de Charles Bloom, développeur de Kraken, Mermaid et Selkie.

La prochaine génération de transistors 3D pourrait remettre la loi de Moore au goût du jour

Publié le par
Répondre

Dans l’industrie des semiconducteurs, la loi de Moore suppose que la quantité de transistors sur une puce double tous les deux ans (la taille de ces puces étant limitée par les processus de production). Jusqu’à présent, bien qu’entièrement empirique, elle a été respectée, même si de plus en plus de gens la déclarent morte : il faut maintenant plus de deux ans pour doubler la densité de transistors. Par exemple, Intel a annoncé avoir changé son cycle d’ingénierie des processeurs : le rythme est toujours d’une nouvelle gamme de processeurs par an, une pour l’amélioration du processus physique (Core 5e génération, dite Broadwell, sortie en 2014-2015), une pour l’amélioration de la microarchitecture (Core 6e génération, dite Skylake, sortie en 2015-2016), puis une d’optimisation (Core 7e génération, dite Kaby Lake, qui devrait commencer à arriver dans les rayons fin de cette année 2016).

Cependant, même les industriels ne sont pas toujours entièrement d’accord avec l’affirmation que la loi de Moore est morte : elle pourrait continuer à s’appliquer dans la prochaine décennie grâce à une nouvelle génération de transistors 3D. Chez Intel et les autres fondeurs qui exploitent des processus 14-16 nm, les transistors actuellement gravés sur les processeurs sont déjà en 3D, des FinFET. Plusieurs de ces transistors doivent être associés pour effectuer une opération sur un ou plusieurs bits, c’est-à-dire former une porte logique (par exemple, le complément d’un bit, le ET logique de deux bits, etc.) ; les fonctions intéressantes des processeurs sont obtenues en combinant ces portes logiques.

Adieu CMOS ?

Les idées en cours de développement dans l’industrie partent plutôt sur un changement de paradigme plus profond que simplement des transistors 3D améliorés. Pour former des portes logiques (par exemple, un NOT), ces transistors sont associés en paires : un seul des deux transistors de la paire laisse passer du courant en sortie, l’autre étant bloqué (ce qui permet de choisir la valeur binaire en sortie, selon la tension reliée à chacun des deux transistors). Ces paires sont donc symétriques (chacun des deux transistors effectue la même opération), mais complémentaires (chacun est relié à une tension différente). Ce principe est à la base des technologies CMOS (complementary metal-oxyde semiconductor), prédominantes sur le marché des semiconducteurs depuis les années 1960.

Cette technologie CMOS a bon nombre d’avantages, comme une consommation d’énergie réduite en fonctionnement statique (le transistor consomme une certaine quantité d’énergie pour commuter, mais presque rien sinon) ou une grande immunité au bruit. Par contre, il est très difficile d’assembler les transistors en trois dimensions. Pour augmenter la densité de transistors sur une même puce, la seule solution, dans le paradigme CMOS, est de réduire la taille de chaque transistor : c’est ce qui est fait depuis des années dans l’industrie, en améliorant les processus de lithographie. En passant dans la troisième dimension, il devient possible d’augmenter la densité de transistors sur une même puce sans forcément changer ces transistors. Il n’empêche que les processus de lithographie doivent s’adapter à cette nouvelle manière de penser.

De nouvelles portes logiques

Ce type de construction devient un choix de plus en plus clair : quand la taille de la plus petite altération du silicium tend vers 10 nm, les courants de fuite à travers les transistors deviennent problématiques. À l’horizon 2020-2025, la situation aura empiré, puisque la lithographie aura atteint des précisions de gravure de quelques nanomètres, c’est-à-dire à peine quelques dizaines d’atomes (un atome de silicium a un diamètre de 0,22 nm). À cela s’ajouteront d’autres problèmes d’ordre quantique (l’effet tunnel permettra à des électrons de franchir un transistor).

Dans cette ère nanoscopique, l’électronique CMOS serait remplacée par des transistors à spin ou des transistors à effet tunnel (TFET), afin de réduire la consommation énergétique (le facteur limitant des processeurs actuels). Ces TFET peuvent fonctionner à des tensions bien plus faibles que les transistors actuels tout en ayant un courant de fuite très faible ; de même, les transistors à spin consomment peu d’énergie (ils stockent l’information dans le spin d’électrons) et seraient très adaptés au stockage non volatil.

Avantages de la construction 3D

Actuellement, cette technique de construction en 3D est nommée 3D power scaling par les industriels. Une version proche est déjà sur le marché : plusieurs couches de silicium sont empilées et connectées verticalement par des TSV, mais chaque couche garde sa logique CMOS. Ces TSV sont à l’origine de la mémoire HBM ou HMC, où les principales difficultés d’assemblage viennent de l’alignement parfait requis entre les différentes couches. 3DPS éviterait ce problème, puisque les transistors seraient construits aussi à la verticale dans un seul processus intégré.

La mémoire NAND (utilisée pour les cartes mémoires et les SSD) utilise déjà des procédés de type 3DPS, avec trente-deux à soixante-quatre couches (notamment chez Samsung). Les industriels estiment que l’avenir des semiconducteurs en général est dans ces puces multicouches, y compris pour les processeurs, voire pour l’électronique de puissance. Le plus gros problème est la dissipation de l’énergie consommée : la chaleur serait alors bien plus concentrée, la recherche de transistors bien moins énergivores est un prérequis indispensable à un déploiement à plus grande échelle des processus 3D ; peut-être faudrait-il alors penser à refroidir les puces de l’intérieur.

Cette nouvelle manière de penser l’organisation des puces aurait d’autres avantages, notamment celui de pouvoir intégrer bien d’autres composants directement sur la même puce que le processeur : les registres pourraient être situés sous les cÅ“urs de calcul, la mémoire à quelques niveaux de la partie calcul du processeur, d’autres circuits pourraient aussi être intégrés. Ainsi, les distances entre toutes ces parties seraient fortement réduites, ce qui limiterait de facto les délais de propagation et pourrait augmenter de manière phénoménale la puissance de calcul disponible. Aussi, les canaux de transmission auraient une section utile bien plus importante qu’actuellement, ce qui limiterait l’impact du bruit.

La recherche est toujours en cours au niveau des transistors adaptés à ces nouvelles directions, mais les industriels ont bon espoir et estiment qu’ils devraient arriver en production dans la prochaine décennie. Bien qu’ils évitent toute annonce au niveau des gains en performance ou des coûts, ils estiment que, grâce à ces technologies, la loi de Moore pourrait même être dépassée.

Source : Next-Generation 3D Transistors Could Rejuvenate Moore’s Law.
Voir aussi : rapport ITRS 2015 (chapitre 9).

Sortie de Mathematica 11

Publié le par
Répondre

Mathematica est un logiciel à l’origine prévu pour le calcul symbolique (spécifiquement pour un public de mathématiciens, d’où son nom), mais qui s’est ouvert à bien d’autres domaines depuis lors : sur ces trente dernières années, son domaine d’action s’est largement étendu en dehors des mathématiques pures, notamment au niveau de la visualisation, du traitement du signal et des images, des statistiques et de l’apprentissage automatique. Avec le lancement de Wolfram Alpha, un « moteur de connaissances numérique », le logiciel a directement eu accès à une pléthore de données diverses, tant sur les éléments chimiques que la sociologie ou la finance, ce qui décuple encore ses capacités. Un résumé de ces domaines est présenté en première page de la documentation. Ces dernières années, les améliorations ont aussi porté sur la manière de déployer ses développements avec Mathematica : le format CDF permet d’exporter des documents (le CDF Player peut exécuter les commandes incluses), Wolfram Cloud propose d’exécuter du code Mathematica dans le nuage.

La version 11 de cet environnement complet propose pas moins de 555 nouvelles fonctions (alors que la première version n’en contenait que 551), sans compter les nouvelles fonctionnalités ajoutées aux fonctions précédentes. Cependant, la rétrocompatibilité est au cÅ“ur des développements : tout programme Mathematica écrit depuis la version 7 restera entièrement compatible avec les dernières versions (il n’y a plus eu de changement incompatible depuis lors) et bon nombre d’applications restent compatibles depuis la première version du logiciel, en 1988.

Cela est possible grâce au principe de cohérence dans la conception de l’interface des fonctions, dans le plus pur style fonctionnel : toute fonctionnalité est prévue pour rester dans la durée, ce qui permet de construire de nouvelles fonctionnalités par-dessus. Quand les développeurs n’ont pas achevé une fonctionnalité, mais qu’elle peut déjà être utile aux différents utilisateurs, elle est proposée sous une forme expérimentale : elle est utilisable, mais il n’y a aucune garantie que l’interface restera inchangée (il faut d’ailleurs inclure spécifiquement des modules, ils ne sont pas disponibles par défaut).

Améliorations esthétiques

En ouvrant Mathematica 11 la première fois, on remarque vite les changements apportés à l’interface graphique, même s’ils sont relativement mineurs. Les polices utilisées sont plus nettes et plus denses. L’autocomplétion a été améliorée, elle est plus contextuelle et fait des propositions y compris pour les options. De plus, chaque commande est maintenant annotée dans la langue de l’utilisateur, ce qui en facilite la compréhension pour ceux qui ne maîtrisent pas suffisamment l’anglais. Les messages d’erreur sont aussi plus instructifs et proposent également d’afficher la pile d’appel au moment de l’erreur.

Impression 3D

L’une des nouvelles zones de fonctionnalités de Mathematica est l’impression 3D. Les versions précédentes pouvaient déjà exporter des géométries en STL, mais la 11 propose toute la chaîne d’impression, depuis la création d’une géométrie 3D à son impression (par une machine locale ou par un prestataire externe) — en prenant en compte les limites techniques de l’impression 3D. Il devient ainsi possible d’imprimer tout graphique tridimensionnel, toute structure moléculaire, toute partie de la Terre (par exemple, la géographie autour d’une montagne).

Apprentissage automatique

Un des grands termes à la mode actuellement est l’apprentissage automatique (en anglais, machine learning), notamment tout ce qui a trait aux réseaux neuronaux et à l’apprentissage profond (Intel et NVIDIA se battent d’ailleurs sur la performance de leurs puces respectives pour l’apprentissage de réseaux neuronaux profonds). La version 10 de Mathematica avait déjà apporté une interface très simple d’utilisation pour bon nombre de cas, avec les fonctions Classify[] et Predict[] pour la classification et la régression (apprentissage supervisé), en donnant accès à une foultitude d’algorithmes sous une interface unifiée (régression linéaire, logistique, forêts aléatoires, plus proches voisins, réseaux neuronaux, etc.).

Cette nouvelle version apporte également une interface unifiée pour l’extraction de caractéristiques, la réduction de dimensionnalité, le groupement d’éléments, la détermination d’une loi de probabilité, l’apprentissage par renforcement. Une nouveauté est aussi la mise à disposition de modèles déjà entraînés, par exemple pour la classification d’images selon leur contenu.

Du côté des réseaux neuronaux, Mathematica s’appuie sur ses capacités symboliques de calcul pour proposer des réseaux représentés de manière symbolique : on peut alors associer n’importe quel genre de couche et visualiser les réseaux, mais aussi les entraîner sur des données (aussi sur GPU) et analyser leur performance, puisque ces réseaux sont stockés comme des graphes. Les couches de base sont déjà implémentées (combinaison linéaire d’entrées, fonctions d’activation sigmoïdes), tout comme les développements récents de l’apprentissage profond (autoencodeurs, réseaux convolutionnels). Les réseaux récurrents sont en cours de développement, mais pas encore prêts.

Géographie

Travailler sur la géographie de la Terre et d’autres planètes n’est pas toujours évident, puisqu’elle n’est pas plate. Mathematica ne fait pas que donner accès aux informations sur bon nombre de planètes, il dispose aussi de fonctions pour effectuer des calculs sur ces géométries particulières : il dispose d’une bonne collection de projections géographiques, pour proposer des calculs précis de géodésie. Ces capacités s’étendent aussi aux cartes, avec l’accès aux détails de chaque rue, mais aussi les frontières historiques de chaque pays et des images satellites de basse résolution.

Calculs numériques

Au niveau numérique, il devient possible de résoudre des équations différentielles (y compris aux dérivées partielles) par leurs valeurs propres dans n’importe quel domaine, y compris en spécifiant des conditions aux limites. Ces solveurs sont totalement génériques : il n’y a pas besoin de connaissances poussées en algorithmique numérique, Mathematica détermine seul une bonne manière de résoudre le problème donné. Ces systèmes fonctionnent en s’intégrant avec les fonctionnalités géométriques préexistantes, ce qui permet notamment d’étudier la réponse d’une peau de tambour qui aurait la forme des États-Unis.

Dans des domaines connexes, le calcul symbolique fait encore des progrès : il devient maintenant possible de résoudre de manière symbolique un grand nombre d’équations aux dérivées partielles qui apparaissent dans les manuels, mais aussi des équations mélangeant des dérivées et des intégrales. Côté numérique, les fonctions d’optimisation ont vu leur performance et leur robustesse améliorées, ce qui sert notamment aux fonctionnalités d’apprentissage automatique.

Programmation généraliste

Même si Mathematica n’a pas commencé comme un langage de programmation généraliste, il s’étend également dans cette direction. Ainsi, il peut maintenant travailler sur des séquences d’octets bruts reçus sur un socket, effectuer des mesures sur un réseau (Ping pour le moment). La cryptographie fait son apparition, tant symétrique qu’asymétrique.

Source et images : Today We Launch Version 11!.
Voir aussi : toutes les nouveautés depuis Mathematica 10.4, mise en contexte de certaines nouveautés.

Sortie de Qt Creator 4.1

Publié le par
Répondre

Qt Creator 4.1 vient de sortir. Cette version mineure apporte pas mal d’améliorations incrémentales à l’EDI, sans le révolutionner. Notamment, deux nouveaux thèmes ont été ajoutés (l’un foncé, l’autre clair), ainsi que deux nouveaux jeux de couleurs pour la coloration syntaxique (basés sur la palette Solarized).


Au niveau fonctionnel, les éditeurs de texte gèrent nettement mieux l’insertion et le saut de caractères : en tapant un guillemet, une parenthèse, un crochet ou une accolade ouvrant, le caractère fermant est automatiquement inséré juste après ; si l’utilisateur supprime le premier caractère, celui que Qt Creator a ajouté est supprimé ; si on tape le caractère fermant quand le curseur est à son niveau, cette frappe remplace le caractère inséré. Cependant, ces comportements (attendus par bon nombre d’utilisateurs habitués à d’autres outils) peuvent être configurés.

Le modèle de code Clang et l’analyseur statique associé utilisent maintenant une version bien plus récente de la bibliothèque-compilateur, la 3.8.1, qui résout bon nombre de défauts. Les problèmes entre Clang et Visual C++, détectés lors de la publication de la RC 1, ont été résolus.

Une autre nouveauté, probablement moins attendue, est une extension pour le langage Nim : elle contient la coloration syntaxique, l’indentation, les styles de code. Il est aussi possible de compiler, de lancer et de déboguer des applications Nim.

Voir aussi : la liste des changements complète.
Télécharger Qt Creator 4.1.0.
Source : Qt Creator 4.1.0 released.
Merci à Claude Leloup pour ses corrections.

Kirigami : KDE présente ses extensions aux Qt Quick Controls

Publié le par
Répondre

KDE est, historiquement, le premier utilisateur dans le monde du libre de Qt. Cet environnement de bureau pour Linux (et autres) s’est construit exclusivement sur la bibliothèque pour son interface graphique. Au fil des années, pour éviter la duplication de code entre les diverses applications, certains composants ont été rassemblés dans des bibliothèques d’extension de Qt, d’abord nommées kdelibs (prévues exclusivement pour KDE), puis récemment transformées en KDE Frameworks dès KDE 5 : les développeurs ont voulu faciliter la réutilisation de composants développés pour KDE dans des applications Qt tout à fait découplées de KDE.

Qt Quick prend de plus en plus d’ampleur côté KDE, notamment pour le développement des plasmoïdes (de petites applications, affichées au niveau du bureau de KDE), mais également pour les applications Plasma Mobile (KDE sur téléphone portable). Pour faciliter ces développements, il a donc été décidé de créer une bibliothèque qui rassemble bon nombre de composants utiles, des briques plus grandes que celles fournies de base par Qt Quick dans le module Qt Quick Components. Il s’agit de Kirigami, qui suit de près la philosophie définie par le projet : une application utilisant Kirigami aura accès à bon nombre de composants graphiques formant un tout cohérent et intuitif pour l’utilisateur.

Parmi les concepts les plus importants de Kirigami, on peut compter :

  • deux tiroirs, un sur chaque côté de l’écran, rassemblent les actions disponibles ;
  • les options et actions sont séparées en deux groupes : les globales et les contextuelles ; chaque catégorie est assignée à un côté de l’écran (et donc à un tiroir) ;
  • le contenu de l’application est organisé en pages, à travers lesquelles l’utilisateur navigue en faisant défiler horizontalement.

Cette description fait d’office penser que Kirigami est optimisé pour l’utilisation sur des téléphones portables. De fait, l’un des principes directeurs était que toute application devait être facile à utiliser avec une seule main. Cependant, la bibliothèque est aussi prévue pour réaliser des interfaces convergentes, qui s’adaptent à la taille de l’écran (et pas seulement avec une mise à l’échelle) : la même application s’adaptera à la taille disponible sur ordinateur et aux stimuli disponibles.

La première application à l’utiliser est la version mobile de Subsurface, passé à Qt il y a deux ans. Une application Android est disponible, la version iOS est en cours de développement et partage presque l’entièreté du code de la version Android (ce qui est un avantage revendiqué par Qt Quick en général).

Côté technique, Kirigami est compatible avec Android, Linux (tant X11 que Wayland) sur plateformes de bureau, Windows, ainsi que Plasma Mobile. La version iOS est actuellement expérimentale, tandis que que celle pour Ubuntu Touch est en travaux. Kirigami n’est pas encore intégrée à KDE Framework 5, mais cela ne devrait pas tarder, en tant que module de premier niveau (c’est-à-dire que la seule dépendance est Qt).

Source : KDE’s Kirigami UI Framework Gets its First Public Release.

Présentation succincte de Qt Gamepad

Publié le par
Répondre

Qt 5.7 est arrivé avec quelques nouveaux modules relativement expérimentaux, notamment Qt Gamepad. Comme son nom l’indique, ce module se destine principalement aux jeux et permet d’utiliser des manettes de jeu directement depuis Qt, c’est-à-dire des mécanismes d’entrée avec des boutons, des contrôles directionnels (comme un manche à balai) et parfois des touches. Ce module fournit tant une interface C++ que QML (ce qui est monnaie courante dans les nouveaux développements, comme Qt 3D). Son API n’est pas encore finalisée (le module reste expérimental) et pourrait évoluer dans les versions de Qt à venir. Au niveau de la compatibilité, l’implémentation utilise les API systèmes de Linux, Windows, macOS, iOS et Android, mais aussi la SDL.

Le module se décompose principalement en trois classes, côté C++. Le singleton QGamepadManager liste les manettes connectées et reconnues (accessibles individuellement par QGamepad) et offre un accès de haut niveau aux événements générés par toutes les manettes. QGamepadKeyNavigation se spécialise dans les signaux d’appui sur les touches. Les composants QML (disponibles dans le module QtGamepad 1.0) portent des noms identiques.

La documentation est assez éparse pour le moment (une seule classe C++, rien côté Qt Quick), ICS propose donc un exemple d’utilisation, exploitant QGamepadManager (au lieu de QGamepad, comme dans les exemples fournis avec Qt 5.7). Celui-ci montre comment lister les manettes disponibles, puis connecte des signaux à chaque événement possible pour en afficher les détails.

GamepadMonitor::GamepadMonitor(QObject *parent)
    : QObject(parent)
{
    qDebug() << "QGamePadManager Demo\n";

    auto gamepads = QGamepadManager::instance()->connectedGamepads();
    qDebug() << "Number of gamepads:" << gamepads.size();

    for (auto i : gamepads) {
        QGamepad *gamepad = new QGamepad(i);
        qDebug() << "Gamepad:" << i;
        qDebug() << "  device id:   " << gamepad->deviceId();
        qDebug() << "  name:        " << gamepad->name();
        qDebug() << "  is connected?" << gamepad->isConnected();
    }

    qDebug() << "\nMonitoring for events...\n";

    connect(QGamepadManager::instance(), &QGamepadManager::connectedGamepadsChanged, this,
        []() { qDebug() << "connected gamepads changed:"; });
    connect(QGamepadManager::instance(), &QGamepadManager::gamepadConnected, this,
        [](int deviceId) { qDebug() << "gamepad connected:" << deviceId; });
    connect(QGamepadManager::instance(), &QGamepadManager::gamepadDisconnected, this,
        [](int deviceId) { qDebug() << "gamepad disconnected:" << deviceId; });
    connect(QGamepadManager::instance(), &QGamepadManager::gamepadButtonPressEvent, this,
        [](int deviceId, QGamepadManager::GamepadButton button, double value) { qDebug() << "button press event:" << deviceId << button << value; });
    connect(QGamepadManager::instance(), &QGamepadManager::gamepadButtonReleaseEvent, this,
        [](int deviceId, QGamepadManager::GamepadButton button) { qDebug() << "button release event:" << deviceId << button; });
    connect(QGamepadManager::instance(), &QGamepadManager::gamepadAxisEvent, this,
        [](int deviceId, QGamepadManager::GamepadAxis axis, double value) { qDebug() << "axis event:" << deviceId << axis << value; });
    connect(QGamepadManager::instance(), &QGamepadManager::buttonConfigured, this,
        [](int deviceId, QGamepadManager::GamepadButton button) { qDebug() << "button configured:" << deviceId << button; });
    connect(QGamepadManager::instance(), &QGamepadManager::axisConfigured, this,
        [](int deviceId, QGamepadManager::GamepadAxis axis) { qDebug() << "axis configured:" << deviceId << axis; });
    connect(QGamepadManager::instance(), &QGamepadManager::configurationCanceled, this,
        [](int deviceId) { qDebug() << "configuration canceled:" << deviceId; });
}

Source, image et code source : What’s New in Qt 5.7.0: Qt Gamepad.
Merci à Claude Leloup pour ses corrections.

Qt Quick et Qt 5.8 : changements pour le rendu

Publié le par
Répondre

À la sortie de Qt 5.0 et de Qt Quick 2, en 2012, l’un des grands changements du côté du rendu était l’utilisation exclusive d’OpenGL 2.0 : OpenGL était vu, à l’époque, comme l’API de choix pour le rendu matériel, peu importe la plateforme (Windows, Linux, macOS, mais aussi sur mobile et dans l’embarqué, avec sa déclinaison OpenGL ES). Cependant, depuis lors, le paysage s’est fortement complexifié.

La solution actuelle ne fonctionne plus

D’un côté, les API de dernières génération ont des concepts radicalement différents (et l’OpenGL nouveau a même changé de nom : Vulkan). De plus, côté embarqué, les processeurs sans GPU OpenGL sont légion, ce qui interdit le déploiement d’applications Qt Quick (à moins d’utiliser une extension autrefois payante, Qt Quick 2D Renderer, compatible avec Qt 5.4 et plus récents). Sur Windows en particulier, l’état des pilotes OpenGL n’était pas toujours excellent (surtout sur les machines où les pilotes graphiques ne sont pas à jour), ce qui impactait directement les applications Qt Quick : dès Qt 5.4, il était possible de choisir, à l’exécution, d’utiliser ANGLE (une implémentation d’OpenGL par-dessus DirectX) ou llvmpipe (une implémentation purement logicielle d’OpenGL).

Ces solutions ne sont en réalité que des emplâtres sur une jambe de bois : un rendu purement logiciel n’est pas envisageable dans bon nombre de situations où la puissance de calcul n’est pas suffisante ; Qt Quick ne peut pas exploiter des API natives, mieux gérées sur chaque plateforme… surtout que le nombre d’API disponibles a fortement augmenté. En effet, le choix ne se porte plus entre Direct3D et OpenGL, notamment puisque les API modernes, de plus bas niveau, sont au nombre de trois : celle d’Apple (Metal), celle de Microsoft (Direct3D 12) et la seule norme multiplateforme (Vulkan). De plus, pour l’ingénierie logicielle, Qt Quick 2D Renderer ne s’intègre pas bien au reste de Qt Quick (il s’agit d’un module séparé).

Une nouvelle génération plus modulaire

Un des objectifs de Qt 5.8 est de refactoriser le code de rendu côté Qt Quick, c’est-à-dire de le découpler d’OpenGL… de le modulariser (c’était le mot clé lors du développement de Qt 5). Ainsi, il devient possible d’utiliser de nouvelles API pour le rendu des scènes Qt Quick, en implémentant une extension qui effectuera la traduction entre le graphe de scène et l’API de rendu. Tout comme il était possible, sous Windows, de passer d’OpenGL à ANGLE à l’exécution, il sera possible de changer d’API à l’exécution. Grâce à l’utilisation d’une représentation assez abstraite de la scène à afficher, chaque extension n’a pas beaucoup de contraintes à respecter dans son implémentation, ce qui permettra de l’utiliser à son plein potentiel.

Cette étape ne fait pas que déplacer des monceaux de code d’un bout à l’autre : des parties de l’implémentation du graphe de scène étaient extrêmement liées à OpenGL. Cela a forcé les développeurs à marquer certaines parties de l’interface publique de Qt comme désapprouvées dès Qt 5.8, de nouvelles API sans ces gênantes dépendances envers OpenGL sont en cours de développement pour les remplacer. Sont notamment concernés les systèmes des matériaux et des particules… mais aussi bon nombre de fichiers d’en-tête dans l’implémentation de Qt Quick : le code C++ incluait ceux d’OpenGL, même si le module Qt Quick 2D Renderer s’occupait de l’affichage (la solution était de définir des fichiers d’en-tête minimaux pour que le code compile — ce qui faisait planter l’application à toute tentative d’appel à OpenGL, forcément impossible).

Direct3D 12 sera le premier concerné par cette refactorisation en profondeur : une extension expérimentale sera livrée avec Qt 5.8 (à côté de celle pour OpenGL, qui garantit la compatibilité avec le code existant), utilisable tant pour les applications traditionnelles (Win32) qu’universelles (UWP). Même si deux gros développeurs derrière Qt (la Qt Company et KDAB) sont membres du consortium Khronos « pour promouvoir Vulkan », il n’y aura pas d’extension pour le moment.

Un moteur de rendu logiciel aux vitamines

Par la même occasion, le moteur de rendu logiciel (ex-Qt Quick 2D Renderer) est retravaillé, notamment au niveau de la performance. Le point principal qui arrivera avec Qt 5.8 est la possibilité de mettre à jour partiellement chaque image affichée, selon les parties qui ont réellement changé dans la scène. Ainsi, une animation qui était autrefois très coûteuse en CPU (une partie pour l’animation elle-même, une plus grosse encore pour redessiner entièrement l’écran à chaque image) deviendra accessible.

L’intégration avec des interfaces à base de widgets avec QQuickWidget sera aussi possible : des applications comme Qt Creator (qui utilisent la classe QQuickWidget) ne pouvaient donc pas utiliser ce moteur de rendu logiciel. Maintenant que le rendu est implémenté au plus près de Qt Quick, le transfert des images entre Qt Quick et les widgets devient possible.

Source : The Qt Quick Graphics Stack in Qt 5.8.
Merci à Claude Leloup pour ses corrections.

Qt WebKit NG TP 3

Publié le par
Répondre

Le projet continue à revivre, entièrement dans la communauté (sans soutien de la part des développeurs principaux de Qt) : Qt WebKit nouvelle génération voit une troisième préversion technique (TP3) arriver. L’une des grandes nouveautés de cette version est la compatibilité avec les extensions NPAPI et Qt (uniquement pour Windows et X11, pas de macOS pour le moment).

Une partie du travail a consisté à s’approcher du niveau de fonctionnalité de Qt WebKit : les balises <object> et <embed> peuvent gérer du contenu avec des images, l’élément <progress> fonctionne comme attendu, les liens <a> peuvent utiliser l’attribut download. L’API Web SQL Database était malencontreusement désactivé, ce qui est corrigé.

Aussi, les développeurs ont ajouté d’autres fonctionnalités par rapport au module Qt WebKit précédent : les événements DOM de niveau 4, la propriété CSS -webkit-initial-letter (qui nécessite Qt 5.8, les raccourcis pour les polices système.

De manière plus générale, la plupart des modifications proposées sur Gerrit depuis Qt 5.2 ont été intégrées : bon nombre de défauts avaient été corrigés par la communauté, sans être intégrés dans le code de Qt WebKit. Il devient aussi possible de compiler Qt WebKit NG sous forme statique, avec les bibliothèques statiques de Qt.

Télécharger Qt WebKit NG TP 3.