Discussion :

[Narann]

Bonjour a tous !

Il y a énormément de documentation sur comment utiliser Qt mais rien sur comment Qt fonctionne sous le capot.

Est-ce que l’un d’entre vous aurait des informations (lien hypertexte, livre, conférence, n’importe quoi) qui pourrait m’indiquer comment Qt fonctionne sous le capot.

Est-ce qu’il calcule tous les pixels de la fenêtre via CPU ? Comment est structurée la hiérarchie de widget a l’écran ? En fait, j’aimerais avoir une vision générale de comment fonctionne le framework, pas de comment on l’utilise.

Merci d’avance !

[dourouc05]

Une grosse partie de Qt concerne les méta-objets, tu peux jeter un coup d'œil à https://louis-du-verdier.developpez.com/qt/fondations/, par exemple.

[LittleWhite]

Bonjour,

On peut aussi tenter l'approche "code source", vu que le code source est disponible. Suffit de se faire une application simple pour tester tel ou tel point de Qt et de plonger dans le code source (à renfort de débogage pas à pas).

[Narann]

Merci pour vos réponses, je viens de lire l’article sur les QObject/moc/méta-objets/etc et il est très intéressant, j’ai beaucoup appris !

Mais il ne répond pas à ma question :

Comment Qt gère l’affichage.

Pour ce qui est du code source, j’ai regardé un peu, mais je n’ai trouvé aucune piste à partir de laquelle creuser. Si l’un d’entre vous aurait la possibilité de m’aiguiller vers des fonctions clefs dans l’affichage de Qt, cela serait un bon début.

[koala01]

Comment Qt gère l’affichage.

Au risque de te paraître (très) brutal, si tu en est encore à poser la question, et surtout sous la forme présente, c'est que la réponse n'aura aucun intérêt pour toi.

Je m'explique:

Qt est un projet qui permet à un développeur débutant de l'utiliser "facilement", mais qui met en oeuvre (en interne) des techniques particulièrement complexes.

Je pourrais donc répondre à ta question en te faisant remarquer que ta question n'est pas assez précise, car la manière de gérer l'affichage dépend du système d'exploitation, et en t'indiquant que Qt fait un usage massif du pimple idiom et même t'expliquer à quoi ressemble cet idiome, mais cela ne servirait sans doute à rien :

Tu comprendrais sans doute la technique, je ne doute pas trop de ce fait. Et puis quoi Tu aurais appris une technique dont tu n'auras de toutes manières aucun besoin avant d'avoir gagné pas mal d'expérience et qui ne facilitera pas ton utilisation de Qt au jour le jour

De toutes manières, Qt est suffisamment bien foutu pour que ces "foutus détails d'implémentations" n'aient aucune espèce d'intérêt dans le cadre de son utilisation "au jour le jour".

Le seul cas dans lequel ils commenceraient éventuellement à avoir un intérêt quelconque serait ... que tu veuilles participer au développement du coeur même du framework, de la partie strictement spécifique à un système d'exploitation donné.

Mais le fait est que, avant de pouvoir envisager une telle participation, il faudra déjà que tu aies acquis non seulement une maîtrise importante du C++ en tant que langage, mais aussi une maîtrise importante de Qt en tant que framework (et, sans doute, une certaine maîtrise du système d'affichage pour le système d'exploitation visé). Et, quand tu auras acquis ces maîtrises, tu te rendras compte que ... tu connais déjà la réponse, et que ta question manquait effectivement de précision...

Du moins, si tu te souvient, à ce moment là, d'avoir initié une discussion sur le sujet "à tes tous débuts".

Il ne faut surtout pas prendre cette remarque pour une attaque personnelle, car elle ne veut sûrement pas en être une. Elle veut juste être un rappel sensé du fait qu'il faut savoir marcher avant de vouloir courir, du fait que C++ est un langage des plus complexes, et du fait que Qt est lui aussi un projet particulièrement complexe.

Or, ces trois faits mis ensembles font que "certaines choses" ne pourront arriver, et avoir une réelle chance d'être comprises que ... quand le moment sera venu, quand les circonstances feront que "tout s'emboîte naturellement".

Je n'émets absolument aucun doute quant au fait qu'il y aura un moment où "tout s’emboîtera" pour toi. Je dis juste qu'il faudra patienter jusqu'à ce que cela t'arrive

Pour ce qui est du code source, j’ai regardé un peu, mais je n’ai trouvé aucune piste à partir de laquelle creuser. Si l’un d’entre vous aurait la possibilité de m’aiguiller vers des fonctions clefs dans l’affichage de Qt, cela serait un bon début.

Si tu tiens à te faire une idée du fonctionnement interne, commence déjà par aller voir du coté des fichiers *.cpp qui se trouvent dans le dossier qtbase/src/corelib/kernel.

Mais je maintiens que ce n'est sans doute pas pour toi "dans l'immédiat".

[Narann]

Bonjour et merci d’avoir pris le temps de répondre.

Vous vous méprenez sur mon expérience et mes compétences.

Ma question est d’ordre culturelle. J’aime bien comprendre comment les choses que j’utilise au quotidien fonctionnent. J’ai énormément utilisé Qt sans trop savoir quel mécanisme/idiome/modèle il utilise pour gérer (au sens « management ») l’affichage des widgets (je sais comment Qt gère les widgets, mais pas comment il les affiche, et je sais que c’est pas via le GPU)

J’aimerais comprendre comment fonctionne (au sens « se gère ») l’affichage des différents frameworks (fltk/wxWidget/Qt). Est-ce qu’il utilise tous une approche similaire, etc.

Merci de m’avoir pointé qtbase/src/corelib/kernel. Je vais creuser un peu la dedans !

Pour spécifier un peu la question :

Je sais ce qui se passe au niveau de la hiérarchie des widgets, de la gestion de la mémoire, j’ai une bonne connaissance en GPU et quelques notions de X. Mais j’ai un gap entre la partie « widget structurés » et comment Qt « dessine les widgets ». Qu’est-ce qu’il cache ? Est-ce qu’il cache, est-ce que c’est l’OS qui cache l’affichage de la fenêtre, etc.

J’ai un « trou » dans mes connaissances entre des concepts avec lesquels je suis a l’aise (management de la mémoire, structure de donne, X, GPU) et l’affichage au niveau de l’OS.

Ducoup, ce que je demandais c’était aussi « qu’est-ce qu’il me manque pour faire la passerelle » entre des connaissances purement informatiques/code/hardware et l’affichage OS.

une certaine maîtrise du système d'affichage pour le système d'exploitation visé

Voila ! Ça c’est déjà un bon élément de réponse. Si tu pouvais m’énumérer quelques concepts à regarder pour élargir un peu ma vision sur le sujet, je suis preneur.

Ce n’est pas les compétences C++ qui me manque (je connais, entre autres pImpl ) c’est plus le nom des concepts que je ne connais pas du tout. pImpl est un bon exemple, si tu sais pas que ça existe, il est difficile de le chercher ou de deviner son nom. Et bien c’est de ce genre d’informations dont j’ai besoins.

Ma question est générale, car elle appelle une réponse générale. Je ne demande pas qu’on m’explique, mais qu’on m’aiguille sur ce que je dois regarder. Après je me débrouille pour creuser.

Merci d'avance !

[koala01]

Bonjour et merci d’avoir pris le temps de répondre.

C'est possible...

Vous vous méprenez sur mon expérience et mes compétences.

Ma question est d’ordre culturelle. J’aime bien comprendre comment les choses que j’utilise au quotidien fonctionnent. J’ai énormément utilisé Qt sans trop savoir quel mécanisme/idiome/modèle il utilise pour gérer (au sens « management ») l’affichage des widgets (je sais comment Qt gère les widgets, mais pas comment il les affiche, et je sais que c’est pas via le GPU)

Tu l'uttilises peut-être de manière régulière, mais il te manque apparemment, encore pas mal d'aspect, car autrement, tu saurais

1. que Qt n'utilise pas forcément le GPU
2. que Qt n'utilise certainement pas les fonction OpenGL ou autres (sauf cas très particuliers-
3. que tout ce qui a trait à l'affichage proprement dit (surtout sous une forme "graphique") passe par des "primitives" spécifiques au système d'exploitation et qu'une grosse partie de la mécanique interne de Qt a pour but de permettre la sélection des primitives adaptée de manière transparente pour l'utilisateur

J’aimerais comprendre comment fonctionne (au sens « se gère ») l’affichage des différents frameworks (fltk/wxWidget/Qt). Est-ce qu’il utilise tous une approche similaire, etc.

Ca, par contre, ca reste à ton niveau

Et la réponse est : non...

Enfin, tout dépend de ce que tu entend par "approche similaire"

L'un dans l'autre, si l'on va "assez bas dans les entrailles" ce sera toujours une histoire de pimple idiome, de "types opaques" et de directives préprocesseurs permettant de sélectionner les directives adéquates pour un système d'exploitation donné.

Mais c'est à peu près le seul point commun que nous pourrons trouver. Ne serait-ce que parce que WxWidget est, à la base, une bibliothèque C, sur laquelle on a plus ou moins essayer d'ajouter une couche de C++, alors que Qt est un framework développé dés le départ en C++.

Quant à fltk, c'est une autre bibliothèque C, qui est partie sur des aspects tout à fait différents de ceux de WxWidget

Je sais ce qui se passe au niveau de la hiérarchie des widgets, de la gestion de la mémoire, j’ai une bonne connaissance en GPU et quelques notions de X. Mais j’ai un gap entre la partie « widget structurés » et comment Qt « dessine les widgets ». Qu’est-ce qu’il cache ? Est-ce qu’il cache, est-ce que c’est l’OS qui cache l’affichage de la fenêtre, etc.

Qt ne saurait pas cacher quoi que ce soit, vu que son code source est intégralement disponible

La seule chose, c'est qu'une bonne partie de ce qui permet justement à Qt de fonctionner aussi bien sous windows que sous linux sera rendu disponible au travers de directives du préprocesseur et / ou de règles de configuration

Le simple fait que linux utilise un serveur (tel que Xorg ou autre) alors que windows utilise ses propres primitives va ainsi prendre une importance absolument capitale

J’ai un « trou » dans mes connaissances entre des concepts avec lesquels je suis a l’aise (management de la mémoire, structure de donne, X, GPU) et l’affichage au niveau de l’OS.

C'est bien le plus compliqué de l'histoire...

Mais, en gros, l'idée est toujours la même (que l'on passe par Xorg ou par les primitives windows):

• On va créer une surface d'affichage (qui correspondra à la fenêtre)
• sur cette surface, nous allons positionner "un certain nombre" de rectangles (de différentes tailles et de différentes couleur)
• sur certains de ces rectangles nous afficherons du texte
• sur d'autres de ces rectangles, nous afficerons des images

Là où cela devient plus compliqué, c'est que chacune de ses possibilités se fera ... d'une manière particulière à l'OS envisagé, et que les types de données que l'on maniuplera eux-mêmes seront spécifiques à l'OS

Ducoup, ce que je demandais c’était aussi « qu’est-ce qu’il me manque pour faire la passerelle » entre des connaissances purement informatiques/code/hardware et l’affichage OS.

Du temps!!! Beaucoup de temps!!!

Le temps de partir d'une implémentation quelconque, et de remonter "de proche en proche" pour retrouver par toi-même les pointeurs vers les informations essentielles.

Puis, encore du temps pour t'intéresser au types réels représentés par ces informations essentielles

Et enfin, encore du temps pour arriver à te faire une idée "plus ou moins précises" de la manière dont ces informations essentielles fournissent les services que l'on attend de leur part.

Le truc, c'est que Qt est "la foire à l'abstraction" : ce sont des abstractions qui utilisent des abstractions, qui manipulent de abstractions...

Si bien que pour arriver à déterminer quel est le type réel de la donnée représentée par une abstraction, pour arriver à trouver le fonctionnement spécifique à un système d'exploitation pour une abstraction donnée, il faut vraiment prendre son temps, et y aller "étapes par étapes".

Ce n’est pas les compétences C++ qui me manque (je connais, entre autres pImpl ) c’est plus le nom des concepts que je ne connais pas du tout. pImpl est un bon exemple, si tu sais pas que ça existe, il est difficile de le chercher ou de deviner son nom. Et bien c’est de ce genre d’informations dont j’ai besoins.

Nous sommes bien d'accord que, si tu ne connaît pas le nom ou, pire encore, si tu ne sait pas qu'un concept existe, il est difficile de partir à sa recherche.

Mais le fait est que la plupart des principes, tu les connais! Ce qu'il te manque, c'est la conscience de toute la puissance qui se cache derrière le principe.

Quand tu crées une collection d'objets polymorphes sous une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::vector<std::unique_ptr<ClasseDeBase> > maList;

c'est une "certaine forme" de pimple...

Simplement, l'usage "classique" que tu en fais est ... très limité par rapport à toute la puissance qu'il peut t'offrir.

Et le fait est que tu pourrais travailler sur dix projets différents sans jamais avoir besoin de toute la puissance qu'il peut t'offrir!

Il n'y aura peut-être qu'un projet sur dix ( sur vingt, sur ... cent) pour lequel l'usage "affaibli" que tu en as ne sera pas "suffisant"; pour lequel tu sera confronté à un problème dont la solution ne sera pas forcément évidente. Et l'idée est d'attendre que tu sois confronté à un tel projet pour que l'on pusse t'expliquer -- exemple à l'appuis -- le "coté obscure" du principe.

Ce n'est pas parce que l'on veut "garder nos secrets", c'est juste parce que, sans exemple concret à te fournir, l'approche que nous tenterions de t'expliquer ne te servira à rien.

La manière dont Qt produit l'affichage en est l'exemple parfait

Ma question est générale, car elle appelle une réponse générale. Je ne demande pas qu’on m’explique, mais qu’on m’aiguille sur ce que je dois regarder. Après je me débrouille pour creuser.

C'est bien là qu'est tout le problème : tu peux commencer à creuser depuis n'importe où, tu arriveras toujours à peu près au même endroit

Il y a plus de 200 000 fichiers dans Qt.

Certains ne servent qu'à fournir quelques informations, d'autre à la génération de la documentation. D'autres encore servent aux tests unitaires ou à la configuration.

Mais ces chiffres devraient te donner une vague idée de la complexité du projet

Rien que pour la partie purement C++ de base (faisons simple: les sources de ce qui se trouve dans le dossier qtbase), il y a plus de 8 000 fichiers, dont une très grosse partie (je n'ai pas fais le calcul, mais nous devons atteindre les 95 ou les 98 % ) sont ... purement et simplement "system agnostic".

Autrement dit, sur 100 fichiers, tu en trouveras sans doute entre 95 et 98 qui se foutent pas mal du système d'exploitation et du compilateur utilisé. Il n'y aura qu'entre deux et cinq fichiers (grand maximum) qui serviront à te dire comment Qt travaille sur un système bien particulier.

L'aspect sympa de la chose, c'est que, quel que soit le coté d'où tu commence à creuser, tu arrivera forcément à l'un de ces quelques malheureux fichiers spécifiques à un système d'exploitation.

L'aspect un peu moins sympa, c'est que, ton debuggeur ne te donnera accès qu'aux sources ... spécifiques au système sur lequel tu utilises Qt (il ne faut pas espérer qu'il t'emmène voir un fichier spécifique à windows si tu es sous linux, ou inversement).

Et donc, si tu es intéressé par le fonctionnement interne de Qt spécifique à un système d'exploitation qui n'est pas celui que tu utilise, tu vas devoir "défaire" tout ce que la configuration -- pour ton système d'exploitation bien spécifique -- a pu faire. Et ca, cela a beau être une approche particulièrement intéressante, elle prend ... un temps bête

[Narann]

Merci beaucoup pour ces informations !

Je sais que Qt n'utilise pas OpenGL, c'est d’ailleurs pour ça que je me demandais comment il faisait.

Par cache, j'entendais "cache de données". Dans notre cas, "cacher les primitives" pour ne pas les recalculer continuellement.

tout ce qui a trait à l'affichage proprement dit (surtout sous une forme "graphique") passe par des "primitives" spécifiques au système d'exploitation et qu'une grosse partie de la mécanique interne de Qt a pour but de permettre la sélection des primitives adaptée de manière transparente pour l'utilisateur

Mais, en gros, l'idée est toujours la même (que l'on passe par Xorg ou par les primitives windows):

On va créer une surface d'affichage (qui correspondra à la fenêtre)
sur cette surface, nous allons positionner "un certain nombre" de rectangles (de différentes tailles et de différentes couleur)
sur certains de ces rectangles nous afficherons du texte
sur d'autres de ces rectangles, nous afficherons des images

Ça donne une vision d'ensemble bien plus clair !

Merci beaucoup !

[LittleWhite]

Je sais que Qt n'utilise pas OpenGL, c'est d’ailleurs pour ça que je me demandais comment il faisait.

Ah bah si. Ils ont plusieurs moteurs de rendu, dont un en OpenGL (sous Windows, implémenter à travers Angle), un autre en pur logiciel et ainsi de suite...

[Narann]

Qt affiche ses QPushButton/QListWidget/QTreeWidget avec OpenGL ?

[dourouc05]

Petit tour dans les sources :
- quand QPushButton doit afficher un truc, il reçoit un événement qu'il traite : https://github.com/radekp/qt/blob/ma...utton.cpp#L444 ;
- le traitement est effectué par QStylePainter : https://github.com/radekp/qt/blob/b8...epainter.h#L87 ;
- celui-ci redirige vers une implémentation de QStyle, par exemple QWindowsStyle : https://github.com/radekp/qt/blob/b8...tyle.cpp#L1790 ;
- tu finis par tomber sur qDrawWinButton, qui dessine un bouton avec le style Windows, à l'aide de QPainter : https://github.com/radekp/qt/blob/b8...wutil.cpp#L415 ;
- cette fonction appelle drawLine, qui elle-même renvoie vers drawLines : https://github.com/radekp/qt/blob/b8...nter.cpp#L4513 ;
- le dessin se fait à travers un moteur QPainter, qui peut être basé sur OpenGL, selon la plateforme.

PS. C'est encore assez fun de faire le tour des sources comme ça . Conseil : prend un environnement de développement (type Qt Creator ou CLion) qui te permette de cliquer sur un symbole pour aller voir ce qu'il y a derrière, ça facilite les choses. Ici, j'y suis allé à coups de Google et du (mauvais) moteur de recherche de GitHub, histoire d'avoir des liens, mais ce n'est pas le plus pratique.

[Narann]

Wow ! Ça c’est de l’introspection ! Merci pour l’aiguillage, ça me permet de bien mieux comprendre l’approche.

[mintho carmo]

On peut ajouter, en plus de OpenGL et Angle, l'utilisation parfois de Metal ou DirectX. Et de Win32 et d'autres API natives. Et Wayland. Et WebGL. Et WebAssembly. Et cela va dépendre des plateformes... Tout cela est géré par le QPA (Qt Platform Abstraction)... donc encore plus d'abstractions.

Bref, pas simple.

A mon avis, lire le code est pas la meilleure approche, c'est difficile d'avoir une vision globale. Il faut mieux lire les tutos et docs. Un bon point de départ, c'est les tutos écrits par les devs. Cf "Tutoriels Qt" > "QT QUARTERLY, QT LABS ET QT DEVELOPER NETWORK" et lire les tutos des Qt Quaterly, des Qt Labs, etc.

@dourouc05 il y a un problème de mises en forme sur ces pages