原創|其它|編輯:郝浩|2009-04-27 09:39:58.000|閱讀 606 次
概述:WPF基礎之體系結構
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
System.Windows.Media.Visual
定義一個系統后,下一步是將像素繪制到屏幕上。Visual 類用于生成可視化對象的樹,每個對象可以選擇性地包含繪制指令以及有關如何呈現這些指令(剪輯、變換等)的元數據。Visual 設計為極其輕量且靈活,所以大部分功能未進行 API 公開,并且極為依賴受保護的回調函數。
Visual 實際上是到 WPF 組合系統的入口點。Visual 是以下兩個子系統之間的連接點:托管 API 和非托管 milcore。
WPF 通過遍歷由 milcore 管理的非托管數據結構來顯示數據。這些結構(稱為組合節點)代表層次結構顯示樹,其中每個節點都有呈現指令。只能通過消息傳遞協議來訪問此樹(下圖右側所示)。
當對 WPF 編程時,您將創建 Visual 元素及派生的類型,它們通過此消息傳遞協議在內部與此組合樹進行通信。WPF 中的每個 Visual 可以不創建組合節點,也可以創建一個或多個組合節點。
請注意一個非常重要的體系結構細節 – 可視對象和繪制指令的整個樹都要進行緩存。在圖形方面,WPF 使用一個保留的呈現系統。這可以使系統以一個高刷新率重繪系統,并且不會發生組合系統阻止對用戶代碼的回調。這有助于防止出現應用程序無響應的情況。
關系圖中不十分引人注意的另一個重要細節是系統實際上如何執行組合。
在 User32 和 GDI 中,系統是在一個即時模式剪輯系統上工作。當需要呈現一個組件時,系統會建立一個剪輯邊界,不允許組件接觸該邊界之外的像素,然后會要求此組件在該框中繪 制像素。此系統在內存受限的系統上工作良好,因為當某些內容更改時,只需要處理受影響的組件即可 – 不會有兩個組件對一個像素的顏色更改起作用。
WPF 使用“繪畫器的算法”繪制模型。這意味著并不是剪輯每個組件,而是要求從顯示內容的背面至正面來呈現每個組件。這允許每個組件在先前的組件的顯示內容上繪 制。此模型的優點是您可以生成部分透明的復雜形狀。與現今的現代圖形硬件比較,此模型相對要快(創建 User32/ GDI 的情況除外)。
如上面所述,WPF 的一個核心原理是移動到一個更具聲明性且“以屬性為核心”的編程模型。在可視化系統中,這會表現為需要關注的兩種情況。
首先,如果您考慮保留的模式圖形系統,則實際上是從命令性 DrawLine/DrawLine 類型模型移動到面向數據的模型 new Line()/new Line()。通過這一向數據驅動的呈現移動,可以在使用屬性表達的繪制指令上進行復雜的操作。從 Drawing 派生的類型實際上是用于呈現的對象模型。
第二,如果評估動畫系統,您將看到它幾乎是完全聲明性的。無需要求開發人員計算下一位置或下一顏色,您可以將動畫表示為動畫對象上的一組屬性。于 是,這些動畫可以表示開發人員或設計人員的意圖(在 5 秒內將此按鈕從一個位置移動到另一個位置),系統就可以確定完成此任務的最有效方式。
System.Windows.UIElement
UIElement 定義核心子系統,包括 Layout、Input 和 Event。
Layout 是 WPF 中的一個核心概念。在許多系統中,可能有一組固定的布局模型(HTML 支持三種布局模型:流、絕對和表),也可能沒有布局模型(User32 實際僅支持絕對定位)。WPF 先假設開發人員和設計人員希望有一個靈活的可擴展布局模型,該模型可能是由屬性值而不是命令性邏輯驅動的。在 UIElement 級別,會引入布局的基本協定 - 具有 Measure 和 Arrange 處理過程的兩階段模型。
Measure 允許組件確定它要采用的大小。此階段獨立于 Arrange,因為在許多情形下,父元素會要求子元素測量若干次以確定其最佳位置和大小。父元素要求子元素測量這一事實體現了 WPF 的另一關鍵原則 – 內容大小。WPF 中的所有控件支持調整到內容原始大小的功能。這使本地化更加容易,并允許在調整大小時對元素進行動態布局。Arrange 階段允許父元素定位并確定每個子元素的最終大小。
通常會花費大量的時間來討論 WPF 的輸出端(Visual 及其相關對象)。然而,在輸入端也有許多創新。WPF 輸入模型的最基本更改也許是一致模型,輸入事件通過系統借助此模型進行路由。
輸入是作為內核模式設備驅動程序上的信號發出的,并通過涉及 Windows 內核和 User32 的復雜進程路由到正確的進程和線程。與輸入相對應的 User32 消息一旦路由到 WPF,它就會轉換為 WPF 原始輸入消息,并發送到調度程序。WPF 允許原始輸入事件轉換為多個實際事件,允許在保證傳遞到位的情況下在較低的系統級別實現類似“MouseEnter”的功能。
每個輸入事件至少會轉換為兩個事件 – “預覽”事件和實際事件。WPF 中的所有事件都具有通過元素樹路由的概念。如果事件從目標向上遍歷樹直到根,則被稱為“冒泡”,如果從根開始向下遍歷到目標,它們被稱為“隧道”。輸入預 覽事件隧道,使樹中的任何元素都有機會篩選事件或對事件采取操作。然后,常規(非預覽)事件將從目標向上冒泡到根。
分割隧道和冒泡階段使快捷鍵等功能在復合世界中表現一致。在 User32 中,您可以通過使用一個全局表來實現快捷鍵,該表中包含您希望支持的所有快捷鍵(Ctrl+N 映射為“新建”)。在應用程序的調度程序中,您可以調用 TranslateAccelerator,它會探查 User32 中的輸入消息,并確定是否有任何消息與已注冊的快捷鍵匹配。在 WPF 中,上述內容不會起作用,因為系統是完全“可組合”的 – 任何元素都可以處理和使用任何快捷鍵。將這個兩階段模型用于輸入,將允許組件實現其自己的TranslateAccelerator"。
為了進一步深化此功能,UIElement 還引入了 CommandBindings 的概念。WPF 命令系統允許開發人員以命令終結點(一種用于實現 ICommand 的功能)的方式定義功能。命令綁定使元素可以定義輸入筆勢 (Ctrl+N) 和命令(“新建”)之間的映射。輸入筆勢和命令定義都是可擴展的,并且可以在使用時聯系到一起。這使得一些操作(例如,允許最終用戶自定義其要在應用程序 內使用的鍵綁定)顯得無關緊要。
至此,本主題已重點討論了 WPF 的“核心”功能 - PresentationCore 程序集中實現的功能。當生成 WPF 時,基礎部分(例如帶有 Measure 和 Arrange 的布局的協定)和框架部分(例如 Grid 的特定布局的實現)之間的明確劃分是希望的結果。目標就是提供在堆棧中處于較低位置的可擴展性點,這將允許外部開發人員可以在需要時創建自己的框架。
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn
文章轉載自:自互聯網