文書處理資料量統計

在 Windows 視窗系統中，主要的文書處理軟體為：Microsoft Word 和 NotePad，

我們分別就這兩樣應用程式進行畫面的剖析和資料量的比較。

5.4.1 Microsoft Word

我們開啟一個存檔的 word 檔案，字型大小為 12 pt，字數約為 300 字，一般的連 線畫面，如下頁圖 62。

圖 62. 一般 RDP 連線開啟 Word

下圖由 rdesktop 進行連線，可以看出開啟後的檔案文字部分也是以點陣圖方式傳 送，除了一些視窗的內框以 rect order 傳送將顯示為綠色矩形，以及部份選單中的文字 以 text order 傳送顯示為紅色字體外，大多數的畫面以 bitmap 顯示，這部份用 memory blt 將暫存 bitmap 依座標位置貼於畫面上。

圖 63. 利用修改後 rdesktop 開啟遠端 Word

瞭解了 Word 畫面組成後，接下來進行資料量的比較，一般來說，Microsoft Word 的使用上除了開啟檔案的瞬間造成畫面資料的大幅更新，在進行文書處理時，畫面更 新頻率取決文字輸入的速度，不論打字速度多快畫面的變化仍然有限，因此 Microsoft Word 的資料量擷取，我們測試的項目為檔案開啟瞬間至畫面更新完畢總共傳輸的資料 量，資料量的比較如下表。

表 20. RDP 連線的 Word 資料量

傳輸資料量 直接傳送 800x600 16bpp Microsoft Word 畫面 960K Bytes

rdesktop 接收 RDP 封包資料量 190K Bytes

節省的資料量 770K Bytes

資料壓縮率 19.8%

接下來分析畫面中各指令所佔傳輸資料量比例，在圖 63.可以看到畫面中少部份為 矩形所繪製外，大部分的畫面都是 bitmap，Microsoft Word 畫面更新是比較特殊的，

RDP 的兩種更新方式不斷互相更新，在檔案開啟後，Bitmap_updates 和 memory blt 重 複更新畫面，更新的部份有重疊的情形，因此在資料量的分析上，我們以各命令（order）

佔傳輸的比例來說明。

表 21. RDP 連線的 Word 命令分析

傳送的命令類別 傳輸資料量(KBytes) 佔傳輸比例 Bitmap cache (header and data) 89.9 47.40%

Bitmap updates(header and data) 76.4 40.28%

Sec、MCS、ISO、RDPlayer 3.5 1.85%

Text order 4.6 2.43%

Memory blt 5.8 3.06%

Font cache (header and data) 5.3 2.80%

Pattern blt 0.04 0.02%

Rectangle order 4.1 2.16%

Total transmit data size 189.64 100%

由於 Word 的畫面傳送，RDP Server 不斷傳送更新過來，其中 Bitmap cache 所傳 送的 Bitmap 僅傳送一次，但是 Bitmap updates 的 Bitmap 仍然不斷傳送過來，這部份 是由於 RDP 的特性為 Server Push，RDP Server 判斷畫面有更新便會傳送資料到 RDP Client，由於畫面有重複更新的情形，因此畫面的資料壓縮部份，僅說明傳送一次的 Bitmapcache 做分析，另外，一次完整畫面中相同的 bitmap 可以利用 memory blt 將 bitmap 從 cache 中取出，下表 22.為這兩項所節省的資料量。

表 22. RDP 連線桌面資料壓縮

傳送的命令 壓縮方式 原始資料量 實際傳輸資料量 壓縮率

Bitmap cache 傳送 bitmap

圖形編碼 831.84K Bytes

89.9K Bytes 10.87%

Memory blt 自 cache 取出 bitmap

Cache 暫存

& 參數指令

187.75K Bytes

0.74K Bytes (僅計算 Memory Blt 資料量)

0.38%

雖然 RDP 連線所傳送的 Word 畫面大部分以 bitmap 呈現，但是 RDP 使用了 Cache，

因此畫面中背景部份，RDP Server 只要傳送 bitmap cache 將點陣圖暫存於 Client 的 cache 中，之後的相同的 bitmap 選擇傳送 memory blt ，依據不同座標重複顯示，由於

RDP 對於 Notepad 的畫面傳送方式不同於 Microsoft Word，在 Notepad 開啟副檔 名為.txt 檔案後，RDP Server 將畫面中的文字以 text order 傳送，背景部份則是以 rect order 傳送，文字及背景的傳送方式和 Microsoft Word 有明顯差異，圖 64.為一般 RDP 連線開啟遠端 Notepad 畫面。

圖 64. 一般 RDP 連線開啟遠端 Notepad

下圖為利用修改後的 rdesktop 進行連線，可以看出文字部分以 text order 傳送，除 了視窗外框，檔案中的背景，綠色部分以 rect order 傳送，另外在選項中的文字底線為 藍色表示以 line order 傳送，文字前景設定為紅色，文字背景則設為淺藍色。

圖 65. 利用修改後 rdesktop 開啟遠端 Notepad

如同前幾節一個完整 800x600 的畫面，假設以 16 bpp bitmap 來傳送，那麼其資料 量為 960K Bytes，相較於 Microsoft Word 的畫面複雜，Notepad 的畫面結構顯得檢單 許多，由上圖可以看出檔案開啟後，除了視窗的外框使用 bitmap 方式傳送外，檔案內 部畫面沒有 bitmap 的部份，完全是以 text order 以及 rect order 組成，因此可以想像 Notepad 開啟畫面的資料量應該不多，經過 rdesktop 連線攫取結果，當我們利用 RDP 傳送過來的資料量比較如下表 24.，實驗結果證明 RDP 的圖形壓縮方式非常適合我們 應用在 thin client 的終端服務上面，利用這樣的壓縮方式，文字部分保留的清晰度，

而且節省了資料量，如果僅以 800x600 16bpp 的畫面來看，傳輸量不到原來的百分之 五，非常適合用於電子看板終端服務上。

表 24. RDP 連線的 Notepad 資料量

傳輸資料量 直接傳送 800x600 16bpp Notepad 畫面 960K Bytes

rdesktop 接收 RDP 封包資料量 33.65K Bytes 節省的資料量 926.35K Bytes

資料壓縮率 3.5%

由圖 65.可以看出畫面中的組成命令為 rectangle order 和文字組成，利用這樣的方 式大幅降低了畫面的資料量，由指令的資料來看，畫面的組成為背景部份填入一個 788x538 pixels 的矩形之後將文字填上去。

表 25. RDP 連線的 Notepad 命令分析

傳送的命令類別 傳輸資料量(KBytes) 佔傳輸比例 Bitmap cache (header and data) 9.61 29.33%

Bitmap updates(header and data) 9.7 29.6%

Sec、MCS、ISO、RDPlayer 0.81 2.47%

Text order 7.48 22.8%

Memory blt 2.8 8.5%

Font cache (header and data) 1.43 4.4%

Pattern blt 0.12 0.4%

Rectangle order 0.82 2.5%

Total transmit data size 32.77 100%