Qt 5.10 pourra créer des documents PDF/A

Le format PDF est utilisé de manière assez universelle pour échanger des documents, au point qu’une version spécifique à l’archivage a été créée : PDF/A. Son succès est tel que certaines institutions requièrent des PDF à ce format pour tout archivage électronique. Cette version correspond à la norme PDF épurée d’une série de fonctionnalités plus complexes, afin de garantir que le rendu soit constant à travers les implémentations : pas de contenu dynamique (JavaScript, audio, vidéo), pas de contenu externe (comme des polices non embarquées).

Qt, de son côté, peut générer des fichiers PDF depuis sa version 4.1, grâce à la classe QPrinter, en définissant son format de sortie à QPrinter::PdfFormat, qui correspond à la norme PDF 1.4. On peut ainsi ajouter du texte dans le fichier PDF de sortie, qui est stocké sous la forme de caractères (ce qui permet une recherche à travers le document et un rendu décent peu importe le facteur de zoom), mais aussi des images (qui correspondront à des images aussi dans le fichier PDF, avec les inconvénients associés : lors d’un zoom, la qualité se dégrade).

La version de PDF/A la plus souvent requise est PDF/A-1b et Qt 5.10 pourra générer des fichiers à ce format. Comme PDF/A-1b est basé sur PDF 1.4, les modifications à apporter étaient assez minimes. Cependant, certaines contraintes ont dû être ajoutées : les images ne peuvent pas inclure de transparence. Deux autres contraintes ne sont pas encore implémentées : les métadonnées doivent être écrites au format XMP et tout profil colorimétrique ICC doit être embarqué dans le fichier PDF.

Pour choisir le niveau de compatibilité PDF, une propriété de QPainter a été ajoutée : pdfVersion, qui peut prendre les valeurs PdfVersion_1_4 (pour obtenir le même résultat que précédemment) ou PdfVersion_A1b (pour exploiter le nouveau code).

Source : Creating PDF/A documents with Qt.

Qt 3D se dotera d’un moteur de rendu Vulkan

Qt 5.10 arrivera, fin d’année, avec une première gestion de Vulkan, c’est-à-dire quelques classes et fonctions pour aider à intégrer une interface codée en Vulkan dans une application Qt. Les développements côté Vulkan ne s’arrêtent cependant pas là en ce qui concerne Qt 3D : en effet, des développeurs de KDAB (à l’origine du Qt 3D actuel) travaillent sur un moteur de rendu basé sur Vulkan pour Qt 3D. Ces efforts sont pour le moment assez limités et toujours en cours, mais ont le mérite d’exister.

Aucune date n’est avancée jusqu’à présent, mais on peut être raisonnablement sûr que le projet aboutira. En effet, l’architecture de Qt 3D est spécifiquement prévue pour permettre des optimisations par rapport à l’API utilisée pour le rendu, grâce à son graphe de trame. De plus, un moteur de rendu Vulkan permettrait, par rapport à son équivalent OpenGL, de libérer quelque peu le processeur de certaines tâches à effectuer, de là limiter la consommation énergétique et augmenter fortement la performance dans des scénarios comme les applications embarquées, actuel cheval de bataille de Qt.

Voir le code actuellement proposé.

Sortie de GammaRay 2.8

La version 2.8 de GammaRay, l’outil d’introspection pour Qt, vient de sortir. Son objectif est de montrer, dans une application, en direct, le comportement du code Qt et de ses structures de données spécifiques. Cette nouvelle version s’est focalisée sur Qt Quick, avec des outils pour gérer les dispositions et Qt Quick Controls 2 (voir l’image ci-dessous) ; plus expérimental, GammaRay offre des possibilités d’analyse du comportement du moteur de rendu logiciel. Par ailleurs, le mode de débogage à distance a été fortement optimisé : dans les versions précédentes, il pouvait sans problème saturer un lien réseau à cent mégabits par seconde — ce qui est dommageable dans l’embarqué. Cette nouvelle version ajoute aussi un navigateur de fuseaux horaires.

Le code C++ créant les QObject est maintenant directement lié à GammaRay, ce qui permet d’ouvrir le fichier source à l’endroit où l’objet inspecté a été instancié. Cette fonctionnalité était autrefois réservée aux projets Qt Quick ; actuellement, elle n’est disponible que sous Linux et requiert (tout comme un débogueur traditionnel) l’accès aux informations de débogage.

Avec diverses améliorations dans la manière de gérer le cycle de vies objets, le navigateur de métaobjet peut montrer des statistiques précises pour les types définis dynamiquement (ce qui est très courant avec Qt Quick et Qt SCXML). Cela facilite la recherche de problèmes dans la création d’objets potentiellement très lourds mais à la durée de vie courte dans les applications Qt Quick.

Source : GammaRay 2.8.0 Release.

Qt 5.9 et OpenVG

Qt 5.9 a apporté une nouveauté presque invisible pour pas mal de gens : le rendu d’applications Qt Quick par OpenVG. Il s’agit d’une API pour accélérer le rendu d’interfaces en 2D sur du matériel où seul le rendu logiciel est possible — principalement, certaines plateformes embarqués (comme les NXP iMX6 SoloLite ou Vybric VF5xxR, qui utilisent le GPU GC355). La dernière version d’OpenVG est la 1.1, sortie en 2008 : la norme n’a rien de nouveau, elle n’évoluera probablement plus, mais reste très implémentée. OpenVG n’a rien de neuf pour Qt : du temps de Qt 4, une implémentation de QPainter pouvait utiliser OpenVG. L’utilisation actuelle est quelque peu plus limitée en termes de fonctionnalités.

L’intérêt d’OpenVG pour Qt est le déploiement sur des plateformes embarquées, où Qt Quick est de plus en plus utilisé. Cependant, avec comme prérequis une implémentation d’OpenGL 2.0, cela limite énormément les plateformes compatibles, surtout dans les segments bon marché, où les GPU ne sont pas compatibles avec OpenGL. C’est déjà dans cette optique que le moteur de rendu logiciel avait été développé. Sa performance peut être largement améliorée si le GPU implémente la norme OpenVG 1.1, tout en gérant la grande majorité des fonctionnalités de Qt Quick.

Dans l’embarqué, cela laisse donc trois possibilités pour effectuer le rendu : purement logiciel s’il n’y a pas de GPU, avec OpenVG si le GPU ne gère pas OpenGL, puis idéalement OpenGL. Ce dernier reste la technologie préférée, puisque le GPU peut largement optimiser les appels effectués : par exemple, sur Raspberry Pi, qui gère tant OpenVG qu’OpenGL, il est plus facile d’atteindre les soixante images par seconde avec OpenGL qu’OpenVG.

Cette implémentation du moteur de rendu est limitée par rapport à celle d’OpenGL. Notamment, tout ce qui concerne la 3D et les shaders n’est pas pris en compte, puisque ces fonctionnalités sortent complètement du cadre d’OpenVG. Les modules comme les particules et les effets graphiques ne pourront pas fonctionner, puisqu’ils dépendent explicitement d’OpenGL.

Source : Getting more out of Qt Quick with OpenVG.

Qt 5.10 accueillera Vulkan : les premiers pas

Les discussions pour une première gestion de Vulkan dans Qt ne sont pas récentes : elles datent de 2016 sur le gestionnaire de tickets du projet, avec les premiers résultats attendus pour Qt 5.10, en fin de cette année 2017.

Ceci se passe dans un contexte double : d’un côté, Vulkan a été développé comme successeur à OpenGL, pour exploiter au mieux les cartes graphiques (notamment pour la réalité virtuelle et des applications aussi gourmandes) ; de l’autre, Qt 5.8 avait pour nouveauté majeure côté Qt Quick une refactorisation du moteur de rendu du graphe de scène, pour le découpler d’OpenGL, avec de premiers travaux pour utiliser Direct3D 12 (l’équivalent Vulkan de Microsoft) pour le rendu de scènes Qt Quick.

Un premier objectif pour faciliter l’utilisation de Vulkan avec Qt est de fournir une série de classes (comme les QOpenGL) qui facilitent l’écriture de code portable. Notamment, la création d’une surface de rendu Vulkan est loin d’être aisée en devant gérer toute une série de plateformes :

QWindow *window;

#if defined(VK_USE_PLATFORM_WIN32_KHR)
    VkWin32SurfaceCreateInfoKHR createInfo;
    createInfo.hwnd = (HWND) window->winId();
    ...
    err = vkCreateWin32SurfaceKHR(...);
#elif defined(VK_USE_PLATFORM_WAYLAND_KHR)
    VkWaylandSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateWaylandSurfaceKHR(...);
#elif defined(VK_USE_PLATFORM_ANDROID_KHR)
    VkAndroidSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateAndroidSurfaceKHR(...)
#elif defined(VK_USE_PLATFORM_XCB_KHR)
    VkXcbSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateXcbSurfaceKHR(...)
#elif ..

Il serait nettement plus pratique (et orienté Qt) d’écrire un code concis et compréhensible comme :

QWindow *window;
VkSurfaceKHR surface = QVulkanInstance::surfaceForWindow(window);

Une gestion de Vulkan dans Qt, même basique, faciliterait donc grandement cette étape très importante dans l’utilisation de l’API. C’est donc le premier objectif de ce nouveau module Qt Vulkan et des classes QVulkan.

Un deuxième objectif à court terme pour ce module est de fournir une abstraction pour une fenêtre dont le rendu est entièrement effectué par du code Vulkan, tout comme QD3D12Window et QOpenGLWindow. Certes, ces classes ont quelques limitations, mais facilitent la prise en main. Ainsi est arrivée QVulkanWindow.

Par contre, pour Qt 5.10, les objectifs ne sont pas beaucoup plus élevés que cela. Notamment, l’API Vulkan n’est aucunement cachée à l’utilisation : Qt aide à créer des fenêtres, à gérer les différences entre plateformes et à charger dynamiquement les fonctions de Vulkan. La nouvelle API n’est, pour le moment, pas du tout utilisée dans des modules comme Qt Quick, Qt 3D, Qt Canvas 3D, QPainter : cela pourrait venir dans le futur, mais pas pour Qt 5.10. Des fenêtres Vulkan peuvent être combinées avec des interfaces à base de widgets à l’aide de la fonction bien connue QWidget::createWindowContainer(), tout comme des fenêtres OpenGL.

Au niveau des plateformes, Qt Vulkan peut être utilisé sous Windows (quand le SDK LunarG est installé et définit la variable d’environnement VULKAN-SDK), Linux (avec xcb, pas encore Wayland) et Android (avec les API de niveau 23 et 24, même si les en-têtes Vulkan ne sont disponibles que depuis le niveau 24).

Les bibliothèques Vulkan sont chargées dynamiquement, c’est-à-dire à l’exécution : il n’est nécessaire que de disposer des en-têtes de Vulkan (une version assez récente, au moins la 1.0.13) lors de la compilation de Qt, pas plus. Dans un futur proche, certaines configurations de test pourraient venir avec une bibliothèque Vulkan, mais ces détails sont en cours de fignolage et devraient être corrigés d’ici à la sortie de Qt 5.10.

Source : Vulkan Support in Qt 5.10 – Part 1.

Les nouveautés de Qt 3D dans Qt 5.9

Qt 3D était une fonctionnalité très attendue pour Qt 5, avec une période de gestation très longue : Qt 5.5 est arrivé avec un moteur 3D, bien que pas encore finalisé (il a fallu attendre Qt 5.7). Son architecture est prévue pour être extrêmement flexible, à tous les points de vue.

Dès Qt 5.9, il devient possible d’intégrer une scène Qt Quick à l’intérieur d’une application Qt 3D (chose impossible précédemment, malgré l’ironie de la situation quand une visualisation Qt 3D est inclus dans une scène Qt Quick). Le cas d’utilisation typique est l’inclusion d’une interface bidimensionnelle sur une surface place — un cas qui deviendra de plus en plus fréquent avec l’avènement de la réalité virtuelle ou augmentée. Cette intégration se fait avec le composant Scene2D (nom choisi pour faire référence à Scene3D, pour inclure une scène 3D dans une interface Qt Quick), qui effectue le rendu de la scène Qt Quick dans une texture et l’affiche à l’endroit voulu dans un objet 3D. Les événements sont bien sûr transférés depuis Qt 3D vers la scène Qt Quick. (Voir l’exemple Scene2D.) Pour des besoins plus simples, l’affichage de texte peut se faire par QText2DEntity.

Le rendu physique (PBR) est maintenant extrêmement utilisé dans les moteurs de rendu afin d’augmenter le niveau de réalisme du rendu. De manière générale, implémenter le rendu physique signifie que chaque matériau doit renvoyer la lumière qu’il reçoit d’une manière propre, pas avec quelques lois prédéfinies de manière stricte. Qt 3D reçoit ainsi deux modèles d’éclairage : QMetalRoughMaterial et QTexturedMetalRoughMaterial, qui implémentent des algorithmes PBR avec des reflets spéculaires de Blinn-Phong. Combinés avec une lumière de type QEnvironmentLight, les réflexions sur l’environnement seront nettement plus naturelles.

Jusqu’à présent, la manière la plus simple de réaliser des animations avec Qt 3D était d’utiliser les mécanismes de base de Qt Quick pour animer des propriétés (en C++, on peut utiliser QPropertyAnimation). Cependant, les graphistes souhaitent souvent des animations bien plus compliquées ; la manière la plus courante de procéder est d’utiliser des images clés. Par ailleurs, les animations de Qt Quick ne permettent pas d’exploiter au mieux le degré de parallélisme permis par l’architecture de Qt 3D.

C’est ainsi qu’apparaît le module Animation. Il implémente exclusivement des animations par images clés pour le moment, c’est-à-dire que la valeur de certaines propriétés est connue à un instant donné (par exemple, après cinq secondes, le bras se lève à hauteur du visage). Cependant, entre ces instants clés, le moteur de rendu doit afficher quelque chose : il interpole donc entre les points connus. Pour le moment, il peut effectuer des interpolations linéaires (lerps) et selon des courbes de Bézier. Ainsi, il est possible de réaliser un très grand nombre d’animations. Les calculs sont principalement effectués en parallèle, dans la réserve de fils de calcul de Qt 3D.

Pour gérer des scènes de très grande taille ou des machines peu puissantes, les moteurs de rendu utilisent depuis belle lurette la notion de niveau de détail : les structures géométriques proches de la caméra sont affichées avec tous leurs détails, tandis que les objets plus lointains n’ont pas besoin du même niveau de fidélité (texture, nombre de polygones, shaders peuvent varier). Qt 3D propose cette notion dans la classe QLevelOfDetail, qui mémorise les différents choix, activés par QLevelOfDetailSwitch.

Qt 5.10 apportera à nouveau son lot de nouveautés pour Qt 3D, comme de nouveaux types d’animation (notamment, un moteur de morphose plus abouti). Dans un futur peut-être plus lointain, Qt 3D pourrait s’enrichir de fonctionnalités orientées réalité virtuelle.

Source et images : What’s new in Qt 3D with Qt 5.9?.

Voir aussi : quelques exemples d’utilisation de ces nouvelles fonctionnalités.

Sortie de Qbs 1.8

Qbs est la prochaine génération d’outil de compilation du projet Qt. Il devrait remplacer QMake à l’horizon de Qt 6. Actuellement, ses avantages sont une compilation plus rapide, avec une facilité d’utilisation plus grande que QMake (qui requiert des astuces de Sioux pour bon nombre d’actions pour lesquelles il n’était pas prévu). La version 1.8 de Qbs s’est focalisée sur la stabilité (tout comme Qt 5.9), malgré une certaine ouverture vers de nouvelles plateformes : les SDK QNX sont gérés, tout comme FreeBSD, le compilateur C++ d’Intel pourrait l’être dans le futur. Qbs est plus utilisable pour Android, en facilitant grandement la compilation d’applications visant une seule architecture, sans trop de code spécifique de la part de l’utilisateur ; il reste du travail, notamment donner accès à la version de Clang du NDK Android.

La syntaxe JavaScript pour accéder aux propriétés des modules a été simplifiée : product.module.property suffit désormais, en lieu et place de product.moduleProperty("module", "property"). Il devient possible de définir des propriétés en lecture seule (avec le modificateur readonly).

Qbs peut maintenant être lancé sans définir de profil, ce qui favorise l’autodétection d’une série de paramètres au lieu de devoir définir soi-même une série de profils. L’objectif principal est de faciliter l’utilisation par des débutants avec l’outil, tout en limitant la charge de maintenance et la dépendance sur des valeurs qui évoluent avec le temps.

Source et détails : Qbs 1.8 released.