L'utilisation d'un descripteur Windows pour sécuriser les appels DirectX à partir du thread bgnd?

Question

Je débogue une application qui est (pour la plupart) une interface utilisateur Winforms sur le code non managé. Un peu du code d'interface utilisateur n'est pas WinForms: il utilise DirectX pour dessiner directement sur la surface de certains composants du Panel. Pour ce faire, le handle Windows du composant est enregistré après sa création, et tous les appels suivants nécessitant un handle que le module qui exécute cet affichage DirectX a besoin (par exemple GetWindowRect()), utilise ce handle. Ce mécanisme est en place depuis un certain temps, sans voir le problème que je vais décrire, bien que nous ayons peut-être eu de la chance. Le programmeur qui a mis cela en place n'est plus disponible pour moi.

Le problème que j'essaie de résoudre est que, par intermittence, l'affichage de cette zone est corrompu. Cette routine est appelée depuis un thread d'arrière-plan. J'ai vu dans mon journal d'application que, par exemple, l'appel à GetWindowRect() va soudainement, et concomitant avec le problème de dessin, renvoyer des coordonnées de garbage. Le handle de fenêtre lui-même n'est pas corrompu et je suis raisonnablement sûr que nous n'avons pas écrasé la structure de données de Windows; Je peux arrêter et redémarrer notre flux d'affichage, et GetWindowsRect(), en utilisant le même handle Windows, recommencera à renvoyer de bonnes coordonnées.

Si cela était au niveau .NET, j'utiliserais Invoke pour reporter le tirage au thread principal. Ma question est, devrions-nous faire la même chose pour cet appel DirectX? J'essayais de trouver l'avertissement de Microsoft à propos de ne pas dessiner dans les threads d'arrière-plan, pour me rappeler si elle s'étend à l'utilisation de poignées Windows; quelqu'un peut-il me diriger vers cela?

PC

Answer 1

Window handles have thread affinity.

L'élément le plus important de l'interface utilisateur est bien sûr la fenêtre. Les objets de fenêtre ont une affinité de thread. Le fil qui crée une fenêtre est celui avec lequel la fenêtre a une relation indissociable . Informellement, on dit que le fil "possède" la fenêtre . Les messages sont envoyés à une procédure de fenêtre seulement sur le thread qui le possède, et en général, modifications à une fenêtre doit être fait uniquement à partir du fil qui lui appartient il. Bien que le gestionnaire de fenêtres permet un thread d'accéder à ces choses comme propriétés de la fenêtre, les styles, et d'autres attributs tels que la procédure de fenêtre , et ces accès sont thread-safe du point de vue du gestionnaire de fenêtres , charge modifier Les séquences d'écriture doivent généralement être limitées au thread propriétaire .