將WPF PathGeometry拆分爲「tiles」

我有一個相當大的PathGeometry（超過100,000個點並且被描邊但未被填充）以顯示給用戶，但只有一小部分路徑在任何時候都可見。爲了澄清，路徑本身不是預先確定的，而是從數據創建。將WPF PathGeometry拆分爲「tiles」

問題：我想提供非常平滑的平移，以便用戶可以探索較大路徑的區域。

我有一個可能的解決方案，但我不知道如何把它關閉。我想要使用拼貼技術 - 將幾何圖形拆分爲拼貼，並只加載可見拼貼。

那麼，如何將一個只有筆畫的路徑幾何體拆分爲多個tile。更具體地說，如何確定給定矩形塊中存在的路徑部分？

我知道我可以使用CombinedGeometry來確定路徑幾何圖形和矩形之間的相交點，但是這將包括矩形（它將被撫摸）的「牆壁」。有沒有更好的方法來平鋪僅筆畫PathGeometry？

謝謝！

來源

2010-08-24 FTLPhysicsGuy

也許不是拼貼只有一個路徑幾何，並使用數據綁定或其他任何方式編程地更改pathdata來表示您放大的路徑段。有點像DeepZoom，但有路徑。這意味着你不必亂七八糟的路徑。

我正在做類似於您的事情，但我在我的路徑中使用的數字略少，因此我沒有考慮使用任何虛擬化方法。但是，我沒有注意到大規模的性能問題。我在滾動查看器中有一個代表大約1000-10000個點的路徑，並且只有當這些點非常遠時我才放大。如果路徑中的點相對靠近它們的鄰居（例如很好的掃描正弦波），那麼WPF會對它們執行某種優化，以防止任何可觀的滯後。

例如：這條路......

multiple sines

...將需要更長的時間比這個路徑來繪製：

simple sine

即使它們含有點相同數量的描述它。儘管實際上在注意到性能有任何差異之前，路徑需要開始像下圖一樣。

the troublemaker

因爲路徑代表音頻波我打算通過執行某種檢查，看是否點創建一個巨大的深藍色塊，並替換它擺脫任何這樣的未來的問題耗電量少，但這可能不是一個足夠的解決方案。

（約在圖像中的大小差異對不起，計算正弦波位是出於行動的時刻所以我只好用老JPEG文件）

來源

2010-08-24 18:48:33

感謝您的回覆。聽起來像是一種很好的技術，因爲在給定用戶平移的區域（例如，知道x_i和x_f，您可以確定要繪製哪些y值）的情況下，您可以輕鬆確定路徑的哪個子節應該可見。如果使用二維非參數化路徑數據會更困難（您如何「快速」找出當前可見的子路徑是什麼樣子）。瓦片背後的想法是預先確定每個瓦片中可見的路徑的子集（最好使用WPF的幾何特徵），並根據需要「快速」顯示/隱藏瓦片。 – FTLPhysicsGuy 2010-08-24 19:59:47

的一種方法是，你加載畫布中的整個幾何圖形。然後在畫布上應用縮放。您可以使用第三方控件，如ab2d。

我已經創建了這樣的畫布，就像在Photoshop中有很多圖紙（由用戶創建）以幾何圖形的形式躺在那裏。我已經使用ab2d來放大其菜單控件，它工作正常。您還可以將預定義縮放設置爲其中的一部分。

感謝/ subho100

來源

2010-09-11 05:27:06 subho

我最近在思考這個自己，所以也許我的經驗可以幫助你。首先，如果你能夠使用StreamGeometry而不是PathGeometry，你可以獲得更好的性能。我建議創建一個StreamGeometry作爲Path的Data屬性，將其放置在畫布上，然後應用Scale和Translate變換來導航形狀。雖然我相信WPF圖形引擎可以很好地擴展，只要你沒有屏幕上的所有點數就可以使用5或6個系列幾何體，每個系統有1000個點（顯然比你提到的數量少得多）與此同時。如果您需要支持「完全縮小」，即所有點都可見，那麼我會建議創建幾何體的低分辨率版本（即更簡單的一組點或位圖）並交換高和低當縮放達到某個級別時，這是-res版本。

這有道理嗎？

祝你好運！

來源

2010-09-16 04:42:49 Matt

感謝StreamGeometry的領導 - 我會研究它。我已經考慮過將其完全縮小的「低分辨率」版本。但是，縮放太多時，縮放和平移選項會產生問題。看到我的另一個問題翻譯在高縮放級別的畫布（http://stackoverflow.com/questions/3523541/translate-a-wpf-canvas-at-high-scale-factors-isnt-smooth-away-from-origin ）。 – FTLPhysicsGuy 2010-09-23 16:49:20

將WPF PathGeometry拆分爲「tiles」

回答

相關問題