2011-08-02 4 views
1

J'ai une application de calendrier hébreu où chaque jour est un UserControl. J'ai 6 étiquettes dans ce contrôle pour la date anglaise, la date hébraïque, les vacances juives et d'autres données définies par l'utilisateur. Lors du défilement, le contenu des étiquettes change lorsque la valeur de la date de l'UserControl augmente ou diminue d'une semaine. Le défilement est sensiblement plus lent que le calendrier Microsoft Outlook, et le profilage révèle que la partie qui prend le plus de temps est la mise à jour du contenu de l'étiquette, qui n'est pas géré par mon code.Mise à jour du texte ralentissant l'application

Y a-t-il un moyen de rendre cela plus rapide? MS Outlook semble avoir un nombre comparable de champs de texte, et le défilement est fluide.

Répondre

3

TextBlocks n'étaient pas sensiblement plus rapide que Labels, mais Glyphs a donné mon coup du lapin de calendrier.

Le remplacement de cette

<TextBlock Padding="5" 
      FontFamily="Narkisim" 
      FontWeight="Bold" 
      FontSize="20" 
      Text="{Binding HebrewDate}"/> 

avec ce

<Glyphs Name="HebrewDate" 
     Margin="5" 
     StyleSimulations="BoldSimulation" 
     FontUri = "/Fonts/nrkis.ttf" 
     FontRenderingEmSize = "20" 
     UnicodeString = "5771 ןושח ה" 
     Fill = "Black"/> 

fait défiler super rapide.

Quelques notes:

  1. Glyphs-je eu supporte pas la liaison, afin de donner à chacun un nom et les mettre à jour dans le code derrière, comme ceci:

    HebrewDate.UnicodeString = zman.HebrewDate; 
    
  2. Glyphs don Pas de fonctionnalité de mise en page afin que le texte hébreu sortait en arrière. J'ai dû prétraiter les chaînes hébraïques avec un reversing function. Même après l'inversion, les points de voyelle hébreu sont sortis mal alignés, donc j'ai retenu Labels pour les cordes qui utilisent des voyelles.

+0

Après avoir été apporté aux larmes il y a quelques années par la manipulation de MS Word de texte hébreu (sens du texte inversant _WITHIN arbitrairement la même word_), je suis frappé par le ** superbe gestion ** de direction de texte dans la Éditeur Visual Studio. Remerciements et merci à MicroSoft pour l'amélioration! –

1

Je ne peux pas être sûr mais il est possible que MS Outlook a été codé dans quelque chose de plus rapide que WPF, peut-être en utilisant DirectX pour montrer les graphiques rapidement. Sinon, je pourrais suggérer de ralentir le nombre de mises à jour en même temps, je suggère d'utiliser un thread supplémentaire pour mettre à jour graduellement les étiquettes au fur et à mesure des cycles de rechange au lieu de tous en même temps, ce qui pourrait causer votre bégaiement .

Questions connexes