Plus les interfaces graphiques modernes évoluent, plus elles utilisent d’effets graphiques… et plus elles demandent de mémoire sur le processeur graphique pour stocker leurs textures. Sur les ordinateurs de bureau, cela n’est généralement pas un problème, même pour les processeurs intégrés, puisqu’ils disposent de bien assez de place — sauf pour les jeux, vu qu’ils utilisent encore plus de textures et, souvent, de plus haute résolution. Par contre, dans le monde embarqué où les ressources sont rares par définition, il faut impérativement limiter son utilisation de mémoire. Une manière pour y arriver est de compresser les textures.Outre les problèmes de mémoire, cette compression apporte d’autres avantages, peu importe l’application. En effet, il faut alors transférer beaucoup moins de données vers le processeur graphique, ce qui économise du temps au démarrage de l’application. Les processeurs graphiques modernes implémentent toute une série d’algorithmes de décompression au niveau matériel, ce qui permet de décompresser les images extrêmement rapidement.
Pour Qt Quick, la compression a souvent été un gros mot. Il y avait certes un exemple textureprovider, mais il fallait écrire une certaine quantité de code C++ soi-même. Qt 5.10 a inclus cette fonctionnalité de base dans Qt Quick, mais sans entrée en grande pompe : on pouvait utiliser directement des fichiers PKM contenant des images au format ETC1 ou ETC2 pour le composant Image. Cependant, avec Qt 5.11, la fonctionnalité est largement améliorée et devient plus facile à utiliser.
Tout d’abord, le conteneur KTX est maintenant géré, la nouvelle norme de Khronos. Ainsi, bien plus d’algorithmes de compression peuvent être utilisés de manière transparente. En pratique, à ce niveau, Qt Quick n’est limité que par les capacités du processeur graphique et du pilote !
Dans le code, rien de spécial à utiliser ce conteneur au lieu d’une image (par exemple, au format PNG). La qualité de l’image est quelque peu altérée par la compression (regardez le bas de la zone verte), mais ce compromis peut être adapté en changeant d’algorithme de compression.
| Code : | Sélectionner tout |
1 2 3 4 5 6 | Grid {
columns: 2
Image { source: "slides.png" }
Image { source: "slides.ktx" }
...
} |
Pour les images transparentes, Qt Quick s’attend à avoir le canal alpha prémultiplié dans les canaux de couleur, pour des raisons de performance. Tout ceci est fait automatiquement pour les formats gérés par Qt Quick. Cependant, pour les textures compressées, cette opération doit être effectuée avant la compression : cela peut être fait par l’outil de compression ou bien par ImageMagick, par exemple.
Maintenant, la vraie nouveauté de Qt 5.11 dans le domaine : que se passe-t-il si le format de compression n’est pas géré (ou si les fichiers correspondants ne sont pas disponibles) ? Par exemple, si l’application est lancée sur un processeur graphique sans OpenGL (ce qui arrive dans le monde embarqué), il ne sera pas possible de décompresser les textures. Bien évidemment, cela n’aurait pas de sens de disposer de plusieurs implémentations de l’interface pour ces différents cas. Qt Quick implémente maintenant une détection automatique de l’extension : à l’exécution, il part à la recherche de fichiers dont la base (sans l’extension) correspond à ce qui est indiqué dans le code QML ; ensuite, il tente de charger d’abord des textures compressées (si OpenGL est disponible), c’est-à-dire avec une extension KTX ou PKM, sinon, il cherche des formats d’image plus standard, comme PNG ou JPG.
| Code : | Sélectionner tout |
Image { source: "slides" }
Source : Compressed Textures in Qt 5.11.
Et vous ?
Qu'en pensez-vous ?