Come disegnare 1216 elementi di canvas senza appendere un'applicazione in WPF

Question

Sto sviluppando un'applicazione Voglio aggiungere alcune icone interessanti. Poiché sto usando la bellissima libreria MahApps, voglio avere una visuale sulle icone in MahApps.Metro/MahApps.Metro.Resources/Icons.xaml, così ho fatto alcune manipolazioni di stringhe per afferrare la parte x:Key di ciascuna riga <Canvas x:Key="appbar_3d_3ds" Width="76" Height="76" Clip="F1 M 0,0L 76,0L 76,76L 0,76L 0,0">. In breve, tutte le manipolazioni di stringhe ho finito con 1216 copie dei seguenti documenti:

<controls:Tile 
Title="appbar_zune" Count="1215" Grid.Row="121" Grid.Column="15" TiltFactor="2" Width="1*" Height="1*" VerticalAlignment="Stretch" HorizontalAlignment="Stretch"> 
<Rectangle Margin="0" Fill="{Binding RelativeSource={RelativeSource AncestorType=Button}, Path=Foreground}"> 
<Rectangle.OpacityMask> 
<VisualBrush Stretch="Fill" 
Visual="{StaticResource appbar_zune}" /> 
</Rectangle.OpacityMask> 
</Rectangle> 
</controls:Tile> 

Si noti che ogni copia del <control:Tile ha le proprietà appropriate Count, Grid.Row e Grid.Column impostate correttamente.

Tuttavia, finisco sempre con il messaggio della finestra Application not responding. Ora, come ho detto, il mio motivo è solo quello di ottenere una visuale su quella collezione di icone carine e invece ottengo un grosso crash dell'applicazione. Voglio solo sapere se c'è un modo per visualizzare una collezione così grande senza danneggiare il computer di nessuno (Nota: il sistema è davvero basso sulla RAM: una delle mie macchine di prova che gira dentro virtualbox).

Answer 1

Per prima cosa, impostare il bind Fill in Mode = OneWay. Scommetto che non hai bisogno che sia TwoWay e potrebbe essere il defalt nel tuo setup. I binding TwoWay costano molto di più.

In secondo luogo, si consideri l'utilizzo di una versione sempre più dura: Mode = OneTime. Dal momento che è improbabile che le icone cambino, non è necessario alcun monitoraggio delle modifiche. Questo ti farà risparmiare ancora più risorse.

Nel tuo caso, First + Second probabilmente non ti darà una grande spinta, ma vale la pena provare e ricordare.

In terzo luogo, che ne dici del tuo VisualBrush es? Tutti usano lo stesso Visual="{StaticResource appbar_zune}"? Allora perché crei migliaia di istanze? Invece di incollare la copia, crea solo un'istanza e fai in modo che tutti gli elementi utilizzino quella istanza. Puoi risparmiare molto tempo e memoria.

In quarto luogo, e più importante e di solito la massima velocità, è - hai tonnellate di articoli. Scommetto che hai qualche scorrimento, orizzontale o verticale. Ma come generi e visualizzi quella pila di oggetti? La creazione di ALL ALL una volta è .. sprecante. Non si adattano tutti sullo schermo, giusto?

Avete alcuni ItemsControl che generano migliaia di elementi? Esaminare la proprietà ItemsPanel di ItemsControl e attivare l'opzione virtualizing su quel pannello. Questo farà sì che si colleghi alla barra di scorrimento e inizierà a creare dinamicamente solo quegli elementi che sono sullo schermo e distruggendo oggetti che si spostano fuori dallo schermo. Beh, l'ho semplificato eccessivamente, ma lascia che funzioni così. Si noti che contenitori come ListBox (e molti altri) è anche un oggetto ItemsControl, quindi si applica anche qui.

O forse hai un enorme file XAML con migliaia di controlli all'interno di alcuni StackPanel senza ItemsControl? Non è davvero saggio. Ma vabbè .. puoi ancora accendere virtualization su StackPanel.

Attivare la virtualizzazione in genere è una buona idea se si dispone di più di poche decine di elementi. È spesso necessario avere un centinaio, ed è un must se si raggiungono migliaia e più. Tuttavia, i costi di virtualizzazione: molto spesso reimposta/reinizializza gli articoli. Se il tuo ItemTemplate è davvero complesso, la virtualizzazione potrebbe far diventare lo scrolling "jaggy/laggy", non so come esprimerlo in inglese, mi dispiace. Il thread del compositore potrebbe semplicemente non avere abbastanza tempo per ricalcolare e ritrasmettere tutti gli elementi in rapido movimento.Se riscontri questo problema, prova a impostare Height degli articoli su un valore costante fisso immutabile. Aiuta molto a velocizzare il layout. ma se il tuo ItemTemplate è davvero malvagiamente complesso, potrebbe non essere d'aiuto neanche. In questo caso senza uscita, l'unica opzione è ... riprogettare e semplificare il modello dell'articolo.

EDIT:

Naturalmente tutto questo non si guadagna nulla se non si dispone di barra di scorrimento e se si sta cercando di visualizzare una tonnellata di elementi contemporaneamente. In questo caso, cerca di semplificare o rimuovere associazioni, modelli, nidificazione dei componenti (a volte è meglio calcolare le posizioni manualmente che utilizzare tre griglie incorporate), use rendering cache o (...) .. Scusa, inizio a fare troppe ipotesi, troppe opzioni ..

EDIT:

ho appena notato Width="1*" e Stretch, quindi probabilmente si dispone di una griglia in alto, non StackPanel. Dal momento che li vuoi uguali, lo UniformGrid potrebbe avere prestazioni migliori. Inoltre, con un po 'di lavoro è possibile aggiungere la virtualizzazione alle reti, anche:

• da 4.5 in su, è molto più facile - article: WPF 4.5 new virtualizing features
• sotto, richiede più lavoro, vedere in 4 parti serie di blog di Dan Crevier:
  • One: http://blogs.msdn.com/dancre/archive/2006/02/06/implementing-a-virtualized-panel-in-wpf-avalon.aspx
  • Due: http://blogs.msdn.com/dancre/archive/2006/02/13/531550.aspx
  • Tre: http://blogs.msdn.com/dancre/archive/2006/02/14/532333.aspx
  • Quattro: http://blogs.msdn.com/dancre/archive/2006/02/16/implementing-a-virtualizingpanel-part-4-the-goods.aspx 0.123.516,41 milaSe la virtualizzazione della griglia non è sufficiente, provare a passare a Canvas e forzare manualmente alcune larghezze/altezze/posizioni. La rimozione del layout automatico a volte consente di risparmiare molto. Quindi, è possibile utilizzare VirtualizedCanvas e se si inseriscono oggetti di dimensioni costanti, probabilmente lo otterrete il più velocemente possibile. Ma questa è l'ultima opzione del resort. Le cose menzionate in precedenza dovrebbero funzionare bene.

Oh, e un'ultima parola sulla virtualizzazione: ricordo che quando ScrollView funziona in modalità virtualizzazione, quindi il Position non è conteggiato in pixel/punti più. In v-mode, la posizione della barra di scorrimento viene contata in items, ovvero posizione = 2,5 significa che lo scroller è a metà del terzo elemento (2 elementi passati e mezzo più), non a pos = 2,5 "pixel" .