Microsoft-ui-xaml: Proposition : la propriété de répartition automatique a modifié les événements dans le fil d'interface utilisateur

Créé le 17 mai 2019 · 3Commentaires · Source: microsoft/microsoft-ui-xaml

Résumé

Autoriser les liaisons d'interface utilisateur à partir de propriétés qui déclenchent des modifications de notification à partir de n'importe quel thread non-UI

Raisonnement

Lorsque vous liez des propriétés, vous devez toujours déclencher une notification de modification de propriété sur le thread d'interface utilisateur, sinon vous obtiendrez une exception d'exécution. Cela provoque la saignée de l'interface utilisateur dans vos modèles et modèles de vue, de sorte que vous pouvez augmenter le thread approprié, ce qui vous empêche d'utiliser INPC à partir d'une bibliothèque standard .NET (sauf si vous souhaitez entrer dans bait'n'switch) .

De plus, vous pouvez avoir des propriétés qui changent plusieurs fois au cours d'une image, de sorte que vous pourriez potentiellement sauter au fil de l'interface utilisateur beaucoup plus de fois que nécessaire (tout ce qui est nécessaire est de marquer la propriété comme "sale" et d'être récupéré sur le prochaine passe de rendu.

Tout cela entraîne une complexité de code considérablement supplémentaire et est plus sujet aux erreurs.

Cela pose également un problème dans WinUI 3.0, car nous avons maintenant deux threads d'interface utilisateur : les threads Legacy UWP et WinUI : sur lequel dois-je augmenter ?

Portée

Doit pouvoir lever INotifyPropertyChanged et INotifyCollectionChanged sur n'importe quel thread
Doit être capable de le faire à moindre coût plusieurs fois par cadre, mais ne déclenchant qu'une seule mise à jour (la dernière dans les victoires)
Doit être capable de gérer une propriété définie pendant sa lecture pour mettre à jour l'interface utilisateur.
Évite de basculer vers le fil d'interface utilisateur s'il y est déjà.

Notes IMPORTANTES

Les problèmes de threading sont bien sûr valables, mais je ne crois pas que ce soit vraiment un problème au final. Peu importe que plusieurs événements INPC se déclenchent avant les mises à jour de l'interface utilisateur, car seul le dernier compterait. Ce ne serait pas différent du code existant basculant plusieurs fois vers le thread d'interface utilisateur. Une fois que le premier passe au fil d'interface utilisateur, la propriété peut déjà avoir été mise à jour plusieurs fois, et donc la dernière dans les victoires.
Naturellement, il devrait y avoir un verrou court lorsque la valeur est lue qui empêche le drapeau sale d'être défini, donc une deuxième série de mises à jour de l'interface utilisateur se produit sur la trame suivante, si la propriété est mise à jour en même temps qu'elle est lue.
En fait, si une valeur, par exemple, passe de false à true et de nouveau à false, la propriété de dépendance est déjà suffisamment intelligente pour détecter que la valeur n'a pas changé et peut être optimisée en ne provoquant pas de nouvelle passe de rendu en raison de la propriété non-changement.

feature proposal team-Markup

Source

dotMorten

👍38

Commentaire le plus utile

C'est une préoccupation très valable, merci de l'avoir soulevée. La prise en charge de l'affinité de thread pour les DP dans le cadre peut ne pas être un gros problème, mais peut très bien l'être pour les implémenteurs d'INPC.

Si du code est capable de déclencher une modification de propriété à partir d'un thread non-interface utilisateur, cela signifie également que le code de sauvegarde de la propriété peut être modifié à partir d'un thread d'arrière-plan. Il peut être protégé à l'aide de verrous, mais les liaisons bidirectionnelles peuvent alors devenir un problème, car elles peuvent bloquer les chaînes de changement de propriété.

Il y a aussi le plus gros problème d'INPC, étant le manque de valeur "actuelle" lorsque l'événement a été déclenché. Il peut y avoir des situations où les propriétés ne sont pas correctement synchronisées (par exemple, SelectedIndex et ItemsSource ne sont pas mis à jour de manière synchrone et SelectedIndex perd sa valeur), ou avec des ping-pong de changements causés par états de propriété (par exemple, modifications de TextBox et filtres regex).

Cela amène alors les problèmes avec INCC, où toute la collection doit être protégée correctement. Par exemple, vous pouvez déclencher un événement faisant référence à un élément qui a été déplacé ou qui n'est plus là.

Je ne dis pas qu'il n'y a pas de solution à ce problème (il y en a certainement) mais les changements d'affinité des threads d'écoute IPNC ne suffisent pas à rendre ce problème facile aux deux extrémités de l'interface.

jeromelaban le 19 mai 2019

👍4

Tous les 3 commentaires

jeromelaban le 19 mai 2019

👍4

WPF a compris cela, alors peut-être tirez-vous simplement la solution à partir de là?

dotMorten le 20 mai 2019

Excellente suggestion. Nous faisons cela pour les événements CollectionChanged (un peu par accident...), nous devrions pouvoir faire de même pour NotifyPropertyChanged.