2010-08-24 17 views
6

Ho una PathGeometry piuttosto grande (oltre 100.000 punti e tratteggiata ma non riempita) da visualizzare per l'utente, ma solo una piccola parte del percorso sarà visibile in qualsiasi momento. Per chiarire, il percorso stesso non è predeterminato ma verrà creato dai dati.Divisione di un WPF PathGeometry in "tiles"

Il problema: voglio fornire una panoramica molto fluida in modo che l'utente possa esplorare le aree del percorso più ampio.

Possiedo una soluzione possibile ma non sono sicuro di come estrarlo. Mi piacerebbe usare una tecnica di piastrellatura - dividere la geometria in tessere e caricare solo le tessere visibili.

Quindi, come si divide una geometria del percorso solo per tratti in tessere. Più specificamente, come posso determinare la porzione del percorso esistente in una determinata tessera rettangolare?

So che posso utilizzare una CombinedGeometry per determinare l'intersezione tra la geometria del percorso e un rettangolo, ma che includerà i "muri" del rettangolo (che verrà tracciato). Esiste un modo migliore per affiancare PathGeometry solo a colpi?

Grazie!

risposta

2

Forse invece di affiancare basta avere la sola patologia e modificare i dati di percorso in modo programmatico usando l'associazione dati o qualsiasi altra cosa per rappresentare il segmento di percorso su cui si è ingrandito. Un po 'come DeepZoom ma con percorsi. Ciò significa che non dovrai fare confusione con i percorsi di fusione.

Sto facendo qualcosa di simile a te ma i numeri che sto usando nei miei percorsi sono leggermente inferiori quindi non ho considerato l'utilizzo di alcun metodo di virtualizzazione. Tuttavia, non ho notato enormi problemi di prestazioni. Ho un percorso in un scrollviewer che rappresenta circa 1000 - 10000 punti e diventa laggy solo quando eseguo lo zoom in avanti solo se i punti sono molto distanti. Se i punti del percorso sono vicini ai loro vicini (ad esempio una bella onda sinusoidale), WPF esegue su di essi una sorta di ottimizzazione per prevenire eventuali ritardi percettibili.

Ad esempio: questa strada ...

multiple sines

... ci vorrà più tempo per disegnare di questo percorso:

simple sine

anche se contengono la stessa quantità di punti descrivendolo. Anche se in realtà il percorso deve iniziare ad assomigliare all'immagine qui sotto prima di notare qualsiasi differenza nelle prestazioni.

the troublemaker

Poiché il percorso è che rappresenta un'onda audio ho intenzione di sbarazzarsi di eventuali problemi futuri come questo eseguendo un qualche tipo di controllo per vedere se i punti sono la creazione di un enorme blocco blu scuro e la sua sostituzione con Qualcosa di meno affamato di potere ma questa potrebbe non essere una soluzione sufficiente per te.

(dispiace per la differenza di dimensioni nelle immagini, il bit che calcola l'onda sinusoidale è fuori di azione in questo momento così ho dovuto usare i vecchi file JPEG)

+0

Grazie per la risposta. Sembra una buona tecnica quando puoi facilmente determinare quale sottosezione del percorso dovrebbe essere visibile data la regione in cui l'utente è filtrato (ad esempio, conoscendo x_i e x_f, puoi determinare quali valori y tracciare). È più difficile se si utilizzano dati di percorso bidimensionali non parametrizzati (come si "individua" rapidamente l'aspetto del sotto-percorso attualmente visibile). L'idea alla base delle tessere era di pre-determinare il sottoinsieme del percorso che sarebbe visibile in ogni piastrella (preferibilmente usando le caratteristiche geometriche di WPF) e "velocemente" mostra/nascondi le tessere secondo necessità. – FTLPhysicsGuy

0

Un modo potrebbe essere, si carica il tutta la geometria in una tela. Quindi applica uno zoom alla tela. È possibile utilizzare controlli di terze parti come ab2d.

Ho creato una tela come quella in Photoshop con molti disegni (creati dall'utente) in forma di geometrie che giacciono lì.Ho ab2d usato per ingrandire con il suo controllo di comando e funziona bene. Puoi anche impostare uno zoom predefinito su una parte di esso.

Grazie/subho100

1

Stavo pensando a questo me stesso di recente, quindi forse le mie esperienze possono aiutare. In primo luogo, è possibile ottenere prestazioni migliori se si è in grado di utilizzare una tecnologia StreamGeometry anziché una PathGeometry. Suggerirei di creare un singolo StreamGeometry come proprietà Data di un percorso, posizionarlo su un'area di disegno e quindi applicare le trasformazioni Scala e Traduci per navigare nella forma. Stavo ottenendo prestazioni decenti con 5 o 6 SeriesGeometries ognuno con 1000 punti (ovviamente molto meno del numero che hai menzionato), anche se credo che il motore grafico WPF scalerà abbastanza bene finché non avrai tutti i punti sullo schermo allo stesso tempo. Se devi supportare di essere "completamente ingrandito", cioè tutti i punti sarebbero visibili, allora ti consiglio di creare versioni a bassa risoluzione della geometria (ovvero un insieme più semplice di punti o una bitmap) e scambiare i valori alti e bassi -res versioni quando lo zoom raggiunge un certo livello.

Ha senso?

Buona fortuna!

+0

Grazie per l'avviso su StreamGeometry: ci penserò. Ho già considerato la versione "low-res" per essere completamente ingrandita. Tuttavia, l'opzione di ridimensionamento e traduzione presenta problemi quando lo zoom è eccessivo. Vedi la mia altra domanda sulla traduzione di una tela ad alti livelli di zoom (http://stackoverflow.com/questions/3523541/translate-a-wpf-canvas-at-high-scale-factors-isnt-smooth-away-from-origin). – FTLPhysicsGuy