! La raison sous-jacente à ce traitement est le fonctionnement de QtWebKit (basé sur WebKit 1). Un explorateur a généralement beaucoup de travail à faire. Il doit analyser le HTML et le CSS, décoder les images JPEG ou PNG en quelque chose qui peut être affiché, générer l’affichage de la page, réagir aux actions de l'utilisateur et exécuter tout le JavaScript du gentil monde du Web 2.0 (à moins que nous ne soyons déjà arrivé au Web 3.0 ?).
Pendant que tout ce travail est en cours, les tâches réseau ne progressent pas si elles s'exécutent dans le même thread que le reste du navigateur. Nous avons constaté, à partir des traces réseau, qu'il se produit ce qu'on appelle des "points de synchronisation" : tandis que QtWebKit est occupé a traiter le thread principal et donc bloque sa boucle de traitement des événements, aucune nouvelle demande n'est envoyée au réseau. Ce qui entraine que, dans le pire des cas, les serveurs HTTP cessent d'envoyer de nouvelles données. C'est particulièrement vrai quant vous avez de faibles capacités de traitement et que la latence réseau est plus élevée que sur le PC de bureau classique (salut le monde des mobile !).
Il y a plusieurs solutions à ça :
- mettre QtWebKit dans un thread et laisser la gestion de réseau dans le thread utilisateur ;
- mettre tout le QNetworkAccessManager dans un thread ;
- mettre le traitement du code HTTP de QNetworkAccessManager dans un thread.
Nous avons adopté la troisième solution.
Techniquement, ceci fonctionne en ajoutant une couche à l'intérieur de QNetworkAccessManager. Le code actuel du protocole de HTTP ne change absolument pas, seule la méthode utilisée par QNetworkAccessManager change. Ainsi, votre code et celui de QtWebKit n'ont pas besoin de modification. Cette technique, disponible à partir de la version 4.8, donne ces avantages sans nécessiter d'activer quoi que ce soit de spécial.
Si vous voulez d'ores et déjà l'utiliser, veuillez jeter un coup d'œil au dépôt de l'équipe terre et pensez à rapporter les bogues
. Si vous voulez jeter un coup d'œil au code, une nouvelle classe (interne) existe dans QHttpThreadDelegate (qui existe dans le thread HTTP) et contrôle le code HTTP. Il est piloté par QNetworkAccessHttpBackend (interne) (dans le thread utilisateur) via des signaux et des slots.PS : beaucoup de choses se produisent à l'intérieur de l'équipe Qt ces jours-ci et vont continuer à se produire, quoique les bruis qui courent indiquent autre chose… Tandis que vous lisez ceci, nous rendons l'utilisation de QtWebKit encore plus asynchrone grâce au "WebKit2 power"
!Source : http://labs.qt.nokia.com/2011/04/29/...accessmanager/