當然本篇的重點不是"真悲慘"之類的，而是這兩個程式設計師都提到了，程式設計的樂趣，甚至有篇是說要怎麼看待這些程式設計師(雖然我覺得有點權力的人都不可能看這種文章)；總之，他剛好跟我之前的文章稍為呼應了一下(喜歡寫程式嗎？)所以，我又決定要來繼續在完全沒時間的情況下開發我的Viewer。
好！廢話一堆！進入主題，之前曾在某一天問完老師問題以後，思考該怎麼樣可以做出地圖分塊處理的功能(想法快記)，雖然沒有時間可以做，但是這個構想還是一值在我腦袋飛來飛去，前幾天把他實做出來了。
希望可以的效果：
*類似Google map當讀取地圖時會有分塊讀取的效果，當某小塊地圖讀取完成後會先在圖面上展示出來；而我原本的設計是整片地圖讀取完成以後才會更新。當然在網路速度很快的時候並不會特別需要這個功能，但是台灣網路你知道、我知道、隔壁剛出生的小妹妹都知道，又貴又慢，所以這個功能需要嗎？我想是YES。
思緒：
1. 詢問老師以後，自覺ByteArray傳遞雖然是一個看似比較炫的方法，但有著必須要完全傳送完畢才能使用的特性，而我也沒有這麼大的能耐自己寫一個串流處理；所以若是要以這樣的方式，就必須要在後台服務部份直接對於要切的圖分別進行處理，而且要分批多次傳送個別ByteArray。(連我自己都不知道這段在寫什麼，總之就是想來想去又變成串流處理器了，所以放棄。)
2. 直接使用快記當中的第一個方法，Viewer設計改成像蒼蠅一樣的多眼方式，也就是利用很多的Image物件來接取不同的區塊的圖像，所以理論上，當地圖需要被更新時，各Image物件會分別對後端送出要求，取得他們所應該顯示的圖資。
實作：
將上述的第二個方法實作，會發現將圖切為較適宜的大小還真的會加快整體讀圖速度(這裡的整體是指一張圖讀完並顯示 VS 小塊圖全部都讀完顯示)，但過多的切塊將會使得速度變慢(原因應該是這時候造成處理延遲的項目從影像網路讀取轉變為後端圖形處理)。整體概念就會像下圖：
當然，如果使用多個Image來呈現地圖，那麼在座標的計算上就變的更為複雜，接圖也變成一個很大的問題。
總之經過繁複的計算以後，來看一下效果，沒有錄動畫，就用連續截圖的方式來看(設定分塊4*4，共16個分塊讀取)：
應該可以發現，這些展示畫面都沒有功能列了，不是為了可以更清楚看到才拿掉，而是如果要採用有分塊功能的Viewer，那就必須要重新撰寫舊Viewer的許多功能，目前只寫了視窗改變大小以後會自動讀圖。XDDDD
沒有留言:
張貼留言