Pourquoi la plupart des frameworks d’interface utilisateur sont-ils threadés?

Par exemple, Java Swing et Android UI utilisent tous les deux un modèle à thread unique dans lequel un seul thread d’interface utilisateur est responsable de la mise à jour de toute l’interface utilisateur. Qu’est-ce qui a amené les concepteurs de framework à choisir un modèle de thread sur l’autre?

Un modèle d’interface utilisateur multithread ne pourrait-il pas vous donner plus de performances, mais au prix d’une complexité accrue? Je me rends compte que le dernier est un gros problème parce que les bogues liés aux threads sont méchants, mais je me demande s’il y a d’autres avantages que le modèle simple-threaded autre que la simplicité?

Qu’est-ce qui a amené les concepteurs de framework à choisir un modèle de thread sur l’autre?

De la gueule du cheval :

AWT était initialement présenté comme une bibliothèque Java multi-thread normale. Mais au fur et à mesure que l’équipe de Java s’est penchée sur l’expérience d’AWT et sur les impasses et les courses rencontrées, nous avons réalisé que nous ne pouvions pas tenir notre promesse.

Cette parsing a abouti à l’une des revues de conception de Swing en 1997, lorsque nous avons examiné l’état d’avancement d’AWT et l’expérience globale du secteur.

(Lisez l’article en entier, il explique la décision en détail et indique que les mêmes problèmes et le passage éventuel à un modèle mono-thread ont déjà eu lieu plus tôt chez Xerox PARC – l’endroit où presque tout ce que nous considérons comme moderne était CS inventé il y a 30 ans)

Un modèle d’interface utilisateur multithread ne pourrait-il pas vous donner plus de performances, mais au prix d’une complexité accrue?

Absolument pas, car dessiner l’interface graphique et traiter les actions des utilisateurs (ce que tout le thread d’interface doit faire) ne sera pas le goulot d’étranglement de toute application 2D sensée.

Un modèle d’interface utilisateur multithread ne pourrait-il pas vous donner plus de performances, mais au prix d’une complexité accrue?

Pas dans la plupart des cas, et cette complexité supplémentaire ferait plus de mal que de bien la grande majorité du temps. Vous devez également vous rendre compte que la structure de l’interface utilisateur doit également prendre en charge le modèle de système d’exploitation sous-jacent. Bien sûr, cela pourrait contourner le modèle et le séparer du programmeur, mais cela ne vaut tout simplement pas la peine dans ce cas.

La quantité de bogues causés par la mise à jour de l’interface utilisateur ad hoc surpasse largement ce que seraient, dans la plupart des cas, des gains de performances insignifiants (s’il y avait même des gains, le threading en fait juste rendre la performance pire souvent.

Dans ce cas, il est préférable d’utiliser plusieurs threads explicitement et uniquement lorsque cela est nécessaire. La plupart du temps dans une interface utilisateur, vous voulez tout sur un seul thread et vous ne gagnez pas grand-chose en utilisant plusieurs threads. Les interactions avec l’interface utilisateur ne sont presque jamais un goulot d’étranglement.

Non, probablement pas. Au moins pas lorsque vous essayez d’exécuter les threads sur le processeur. Sur le GPU, il existe déjà beaucoup de traitements parallèles sous différentes formes. Pas tant pour le travail graphique simple, mais pour la 3D sophistiquée (ombrage, reflections, etc.)

Je pense que tout est une question de prévention des impasses.

Les composants de Swing ne sont pas considérés comme thread-safe, et ils ne doivent pas nécessairement être à cause de ce thread de disjoncteur d’événement. Si l’interface utilisateur était multithread, l’application entière devrait compter sur chaque composant se comportant de manière sécurisée et, le cas échéant, des blocages pourraient survenir dans des situations obscures.

Donc, c’est juste plus sûr.

Non seulement cela, mais le même design a été choisi par Windows Forms (& .Net), GTK, Motif et divers autres. Je me demande si Java aurait été forcé dans cette décision par les API OS sous-jacentes avec lesquelles ils interagissent. Certainement, SWT est forcé dans cette situation par Windows Forms.

Pour plus d’informations, “EDT” est un bon endroit pour commencer http://en.wikipedia.org/wiki/Event_dispatching_thread

Pour .NET, l’équivalent de SwingWorker est appelé BackgroundWorker.

Cela est dû à la nature d’une application d’interface utilisateur.

Vous devriez lire l’entrée (souris ou clavier), dissortingbuer les événements, les laisser traiter et dessiner l’écran à nouveau.

Essayez de le faire sur un processus multi-thread.