專利名稱：：一種界面庫架構方法
技術領域：
：本發(fā)明涉及軟件開發(fā)庫，具體的說，是涉及一種界面庫的架構方法。技術背景軟件的"UI界面"是應用軟件與應用軟件的用戶之間進行交互活動的載體。不同應用軟件的界面可以是千變萬化的，但其中會有許多交互邏輯相對獨立的元素，它們有相同的交互邏輯和相似的顯示，簡單的例如用于顯示一行文字的靜態(tài)文本框、按鈕、用于接收輸入文本的編輯框等等；復雜的比如一組互斥按鈕、Tab等組合控件。這一類各個界面都能通用的元素，我們稱之為UI界面控件或UI界面組件。應用軟件的每一個界面都可以看作是數個UI界面控件的組合。而這些UI界面控件的實現完全可以放在一個通用的庫中。界面庫實際上就是提供給應用軟件開發(fā)人員的一個工具包，提供已封裝好的UI界面控件給軟件開發(fā)人員使用，使得使用者無需關心每一個UI界面控件內部的邏輯實現，而只需要關心和管理控件與控件之間的業(yè)務邏輯關聯和數據傳遞即可。通常一個完整的界面庫大致應包含了以下幾個方面的設計(A)—組UI界面控件類及它們的對外操作接口；(B)控件管理器或界面庫管理器；(C)用于調用不同繪制引擎的繪制接口。其中，(A)是每個界面庫必須包含的內容，應用軟件開發(fā)者在使用界面庫時，必須通過每個控件的接口操作這些控件以改變控件的狀態(tài)、表現等。(B)的控件管理器是指用于管理所有屬于同一界面庫體系的UI控件之間的隱式聯系的一個或一組對象。這種隱式聯系與業(yè)務邏輯無關，僅與界面表現與交互響應相關，例如控件與控件之間由于某種關系(最常用的就是樹型結構)而形成的位置遮擋、顯示順序、消息分發(fā)與傳遞、界面更新策略等等。并不是所有的界面庫都會有這類對象。在windows系統中，如果界面庫的每個控件都擁有一個windows窗口句柄，那么它即隱式地使用了操作系統作為它的控件管理器，操作系統會替它完成上述所有的管理工作。而對于在游戲中使用的的界面庫，由于所有控件共用一個windows窗口，勢必需要一個控件管理器來管理這種關系。有時，游戲要求的高刷新率使得界面庫管理器拋棄更新區(qū)域處理功能，而采用定時(或在空閑時)更新整個界面的方式。一些界面庫的控件管理器不僅實現這種控件之間關系的管理，還管理界面庫的一些全局信息，如使用繪制引擎的類型，界面庫風格等等，以提高其通用性，適應不同應用軟件的需求。在設計UI庫時，如果讓UI控件在繪制時調用另一個對象做繪制工作，這個對象就叫作繪制引擎或對繪制引擎的一個封裝。調用接口即稱為繪制接口，它通常在游戲界面使用的界面庫中出現。游戲界面由于需要較高的刷新率和更豐富的界面表現，一般不會使用微軟公司的windowsGDI繪制引擎，而使用第三方開發(fā)的各種專門繪制引擎。而3D游戲則必須要使用這種繪制接口方便地更換專用的3D繪制引擎。桌面應用軟件由于對用戶界面的顯示要求不高，使用的界面庫通常在控件內部使用windowsGDI進行繪制即可，并不把這種操作獨立出來，應此也沒有繪制接口的設計。這種界面庫的架構設計，對于想更換繪制引擎的需求將十分不利。目前界面庫的架構設計根據應用場景可以分為兩大類一類應用于桌面軟件，即使用微軟公司的windowsGDI繪制界面，不需要控件管理器和繪制接口設計，這類界面庫的缺點是由于繪制引擎(GDI)功能和結構的局限，無法方便地實現更豐富的用戶界面表現(如控件半透明等)。另一類應用于2D或3D游戲，采用了繪制引擎接口設計，可以使用第三方專用繪制引擎表現更豐富的用戶界面。但由于控件管理器是在一個windows窗口句柄的基礎上管理所有控件，使得界面庫的使用者無法在這種控件體系中使用帶有windows窗口句柄的子控件，即開發(fā)桌面應用軟件如果想使用這種界面庫，那么在其中加一個有windows窗口句柄的控件會十分麻煩，這樣就大大局限了桌面應用軟件使用控件的種類；同時，當應用軟件每次更新整個界面時，將會占用大量的CPU資源，從而導致電腦的操作反應速度變慢，直接影響用戶的使用感受。以上的這些問題，是在某些特殊的應用軟件開發(fā)場景，例如開發(fā)桌面網絡游戲軟件(比如騰訊一^司的qq寵物軟件)時產生的。這種應用軟件的特點是，既有多窗口桌面軟件界面的需求，某些界面又要達到游戲引擎的繪制水準，目前軟件設計界尚沒有出現能夠同時滿足這種需求的單一界面庫。進一步的，基于上述的這些問題，軟件開發(fā)界面庫的設計者自然的會想到一種解決方案，即對于上述的這種桌面網絡游戲軟件的界面庫需求，可以采用兩套界面庫和兩種繪制引擎同時使用的方案對于界面表現要求不高的界面，使用基于windowsGDI的桌面軟件界面庫，對于界面表現要求高的界面，使用游戲專用界面庫。但是，這種解決方案的缺點是(1)需要同時維護兩套界面庫，工作量大，成本較高；(2)在桌面軟件界面庫實現的界面上還是無法實現較豐富的界面效果。
發(fā)明內容本發(fā)明所要解決的技術問題是，提供一種能夠滿足桌面游戲軟件界面開發(fā)需求，組件維護又非常簡單的界面庫架構方法。本發(fā)明的界面庫架構方法是這樣實現的一種界面庫架構方法，其特征在于，自上而下依次包括了用戶層，控件層，場景幻燈片層和引擎層；所述用戶層通過創(chuàng)建控件層對象和調用控件層接口操縱界面元素；所述控件層包括了所有獨立控件或組合控件，控件操作場景幻燈片層的場景對象和圖層；所述場景幻燈片層包括了場景對象和圖層，場景對象管理控件圖層的繪制及更新，圖層調用引擎層的繪制引擎接口將圖層繪制在控件的畫布上；所述繪制引擎層包括了繪制引擎接口，接受來自場景幻燈片層的圖層的調用，實現圖像和文字的繪制。優(yōu)選實施方式是，控件層以一個頂層窗口體系為一個基本管理單位，在體系中以一棵樹描述體系中所有控件的父子關系，樹上的每一個結點為一個控件。優(yōu)選實施方式是，所述控件包括了有窗口句柄的控件和無窗口句柄的控件；所述有窗口句柄的控件由用戶層的用戶創(chuàng)建后，生成窗口畫布并創(chuàng)建相應的場景對象；所述無窗口句柄的控件由用戶層的用戶創(chuàng)建后，使用父控件的畫布和場景對象，或者由用戶層的用戶設置該控件的畫布和場景對象；所述場景對象管理該控件圖層以及該控件的無窗口句柄子控件圖層的繪制及更新。優(yōu)選實施方式是，所述控件包括了可見控件和不可見控件；所述不可見控件用于控制多個邏輯相關的控件；所述可見控件包含一個多狀態(tài)背景層，所述背景層由一個背景層工廠才艮據背景圖片的身并接方式創(chuàng)建。優(yōu)選實施方式是，所述場景幻燈片層中的場景對象使用線性列表結構保存每個圖層在此場景上的位置信息。優(yōu)選實施方式是，所述控件層的狀態(tài)發(fā)生改變時，通知場景幻燈片層；場景對象將該圖層所在區(qū)域收集入更新區(qū)域列表，并通知畫布進行更新。優(yōu)選實施方式是，所述控件層的狀態(tài)發(fā)生改變時，通知場景幻燈片層；場景對象將該圖層所在區(qū)域收集入更新區(qū)域列表；場景對象利用CPU空閑或定時器定時更新畫布。優(yōu)選實施方式是，所述繪制引擎層繪制圖像時，先使用圖像工廠創(chuàng)建圖像對象，并根據圖像對象的格式、畫布對象的格式、混和模式創(chuàng)建混和器，混和器根據設定的混和參數將圖像對象繪制到畫布對象上。優(yōu)選實施方式是，所述繪制引擎層繪制文字時，先使用文本工廠生成文字對象，并根據文字對象格式、畫布對象格式、混和模式生成混和器對象，混和器對象將文字對象繪制到畫布對象中。實施本發(fā)明的一種界面庫架構方法，由于可以在桌面窗口模式中使用游戲繪制引擎，因此能4艮好地滿足桌面網絡游戲軟件的界面需求；同時，場景幻燈片層的架構設計，使界面庫可以支持桌面軟件和游戲軟件兩種刷新模式和多種繪制引擎，因此，分離出來的控件層和圖層模塊可以作為獨立的部分被兩者復用，這大大方便了組件的維護。圖l是本發(fā)明的架構模塊示意圖；圖2是本發(fā)明控件架構的示意圖；圖3是本發(fā)明實施方式的模塊示意圖；圖4是本發(fā)明中控件背景層創(chuàng)建圖；圖5是本發(fā)明畫布被動更新時序圖；圖6是本發(fā)明繪制51擎層繪制圖像時序圖；圖7是本發(fā)明繪制？1擎層繪制文字時序圖。具體實施方式下面，結合附圖對本發(fā)明作進一步的說明。如圖1所示，本發(fā)明的一種界面庫架構方法，自上而下依次包括了用戶層，控件層，場景幻燈片層和引擎層。它們排列順序的意義是(1)上層部分只能使用臨近的下層的對象，不能越層調用；(2)下層對象不知道上層對象。本發(fā)明界面庫架構方法的架構中，最上層是用戶層，即界面庫的使用者(桌面游戲軟件的開發(fā)者)，用戶層通過創(chuàng)建控件層對象和調用控件層接口來操縱界面元素?？丶影歇毩⒖丶蚪M合控件的實現。這些控件由一棵樹來管理父子關系，這棵樹構成了一個頂層窗口管理體系，樹上的每一個結點為一個控件。這些控件可以是建立在一個真實的windows窗口基礎上，即帶有windows窗口句柄(HWND)，可以交由windows窗口體系來管理；也可以是一個邏輯上的窗口，即無windows窗口句柄，由本系統中的窗口管理系統管理。而本系統在邏輯上將這兩種窗口納入了一個管理體系。有窗口的控件2和無窗口的控件3都可以是控件1的子控件，而控件1可以是有窗口也可以是無窗口控件(如圖2所示)。由于每個控件的顯示是一個圖層或數個圖層顯示的疊加，每一個真實的windows窗口都擁有一塊畫布作為它的圖層最終顯示的場所(最簡單的畫布就是窗口DC)和與其相對應的一個場景對象，無窗口控件則使用父窗口的畫布作為自己的畫布。場景對象用于管理它所對應的畫布上應顯示的所有圖層的繪制及更新，但它并不需要關心這些圖層是屬于哪一個控件的，因此，如圖2所示，控件l的場景l(fā)對象管理了圖層l、圖層4、圖層5三個圖層，而控件2的場景2對象只管理它自己的圖層2和圖層3兩個圖層。在本發(fā)明的界面庫架構方法架構中，每個圖層通過調用引擎層的對象將自己最終繪制在所屬的畫布上。在頂層窗口管理體系中，通常頂點控件一定是一個真實的windows窗口，這樣所有的圖層都可以找到一個場景管理自己。但如果頂點控件是非真實的windows窗口，那么需要從外部由桌面游戲軟件的開發(fā)者單獨設置畫布和場景對象?？丶縿?chuàng)建一個圖層，都將它加入控件應顯示的畫布所對應的場景對象中。在具體的實現方案中，每一個有窗口句柄的控件都會創(chuàng)建自己的場景對象，并將這個場景對象的指針傳遞給它的所有無窗口句柄的子孫控件。所以，每一個場景所管理的圖層有可能分屬不同的控件。在實現中，通過查找本控件的最后一個圖層在列表中的位置后插入新增圖層，保證了同一個控件的圖層在場景中的連續(xù)排列。前面提到，本發(fā)明的界面庫架構方法架構中可以同時管理有窗口句柄控件和無窗口句柄控件，一個控件無論是否有窗口句柄，都可以擁有有窗口句柄的子控件或無窗口句柄的子控件。統一控件體系管理決定每一類控件只有一個供外部使用的控件接口，但可以有兩種實現方式有窗口句柄實現和無窗口句柄實現。在本界面庫架構方法設計中，它們共用一個對應于該控件的邏輯組件。如圖3所示，表現了一個對話框(Dialog)控件的實現方式每一個控件都有一個"DialogCore"模塊，用于管理該控件的狀態(tài)邏輯和所有顯示圖層。對于一個按^L,有窗口按鈕與無窗口按鈕的公用邏輯就是當按鈕響應鼠標消息時，按鈕的背景圖層會根據鼠標狀態(tài)的變化發(fā)生改變。并向外界派發(fā)點擊消息。但對于控件的其它操作，如在整個控件體系中的動作，這兩種控件的實現在某些方面又各不相同，需要分由兩個不同的對象來實現。其具體不同點如下表所示行為有windows窗口句柄的控件無windows窗口句柄的控件創(chuàng)建創(chuàng)建畫布和場景不用創(chuàng)建畫布和場景，使用父控件的場景管理圖層移動沿控件樹向上查找自己真實父窗口，換算坐標后，移動真實窗口移動所屬圖層，同時移動所有子控件顯示(隱藏)顯示(隱藏)真實窗口顯示(隱藏)所屬圖層，同時顯示(隱藏)所有子控件設置焦點設置自己的窗口為焦點窗口查找場景對應的窗口句柄，^沒置它為焦點窗口設置是否可用設置自己的窗口屬性僅需要將該控件ID標志為可用或不可用設置父控件查找自己的真實父窗口后，設置自己窗口的父窗口，重新換算坐標位置并移動查找自己的真實父窗口，重新計算所屬圖層在新場景中的位置和clip區(qū)域，并移動圖層。重新設置所有子孫<table>tableseeoriginaldocumentpage13</column></row><table>以上只例舉了具有代表性的不同點實現方案。由表中可以看出，無論是有窗口控件，還是無窗口控件，它們在體系中的行為和表現的本質都是對場景和層的操作。根據上面所述，控件的邏輯和控件的繪制更新在實現上是完全分離開來的?？丶趧?chuàng)建時將自己擁有的圖層的繪制和更新全部交給某個場景對象去管理，控件自己只需要關心軟件的業(yè)務邏輯，比如對輸入消息(鼠標，鍵盤等)的響應處理和由此引發(fā)的圖層顯示狀態(tài)(是否顯示，顯示位置等)改變等；而圖層在場景對象的管理下，可以調用各種繪制引擎的繪制接口，完成各種界面的繪制需求，包括圖像的繪制和文字的繪制等。因此，本發(fā)明的這種界面庫架構方法，可以在桌面窗口模式中使用游戲繪制引擎，能很好地滿足桌面網絡游戲軟件的界面需求；同時，場景幻燈片層的架構設計，使界面庫可以支持桌面軟件和游戲軟件兩種刷新模式和多種繪制引擎，并且，分離出來的控件層和圖層模塊可以作為獨立的部分被兩者復用，這大大方便了組件的維護。在本發(fā)明界面系統中控件類型從功能角度看又分為兩大類可見控件和不可見控件，不可見控件又稱為控制型控件。可見控件指那些具有表現的控件。不可見控件主要用于控件多個邏輯相關的控件，其本身不需要表現。絕大多數可見控件包含一個多狀態(tài)背景層。背景層根據背景圖片的拼接方式由一個背景層工廠創(chuàng)建出來，這極大方便了背景層種類的擴充。請參閱圖4所示VariableParam是外界傳給控件的參數集對象?？丶⑺咏o背景層創(chuàng)建工廠，由工廠創(chuàng)建具體對象，并根據參數集中的數據初始化這個背景圖層。最后由工廠返回一個IBGLayer指針給控件。場景(Scene)和圖層(Layers)是本界面體系繪制過程中抽象出來的兩個基本對象。可以作一個比喻場景相當于幻燈片框，而圖層相對于幻燈片。許多重疊或不重疊的幻燈片，按一定的順序排放在幻燈片框中，最后沖殳射到墻上的白布(Canvas)上，這個過程，就是本界面體系中所有界面的繪制過程。當然，相對于幻燈片框，Scene需要作更多的事情。每一個圖層是一段相對獨立可復用的繪制邏輯。它可以只包含單個簡單元素，例如一幅圖、一^a文字、一個邊框、一個閃爍的光標等等；也可以是多個圖層的集合，如由三張圖或九張圖拼接而成的背景圖層，可根據狀態(tài)ID變換表現的多狀態(tài)圖層，多幀動畫圖層等等。在本發(fā)明實現的UI庫系統中實現了上述所有圖層組件。每個類型的圖層類都繼承于一個父類ILayer,可以通過它的接口獲得得每個圖層組件的公共屬性。圖層組件有以下公共屬性1)圖層的尺寸；2)圖層的可見性(Visible);3)圖層的剪切區(qū)域(ClipRegion)。圖層的尺寸通常由包含圖層內容的最小外接矩形的長寬描述，它體現圖層在無遮擋且畫布足夠大的情況下繪制內容的真實范圍。圖層的可見性決定圖層最終是否被繪制到畫布上。根據普遍使用的父子控件顯示邏輯當子控件圖層超出父控件范圍時，超出部分不可見，即不可以被繪制。除去不可繪制部分，圖層實際需要繪制的區(qū)域即它的剪切區(qū)域。每一類圖層要根據圖層的具體內容選擇在剪切區(qū)域中繪制圖層的算法。在本發(fā)明的UI庫系統中使用矩形區(qū)域列表記錄圖層剪切區(qū)域。圖層并不含有位置信息，圖層位置取決于它^皮;改置的場景(Scene)。Scene管理一組圖層的繪制位置、繪制順序和更新區(qū)域。在Scene對象中，使用線性列表(list)結構保存每個圖層在此Scene上的位置信息。列表是有序的，繪制時靠近列表頭部的圖層先被繪制，靠近列表尾部的圖層后被繪制。當Scene將自己管理的所有圖層繪制到Canvas上時，根據傳入的Canvas上起始坐標將圖層的Scene坐標轉:換成Canvas坐標后再調用圖層的繪制接口，將圖層繪制到Canvas上。Scene另一個重要的設計功能是收集更新區(qū)域并提供更新區(qū)域合并處理。Scene管理的設計決定Scene可以支持界面通常使用的兩種更新方式1)當界面局部顯示發(fā)生變化時才通知畫布更新(Canvas被動更新)；2)利用CPU空閑或定時器定時更新畫布(Canvas主動更新)。對于1)更新方式，請參閱圖5所示，在桌面軟件界面實現中，使用前一種方式，控件圖層的狀態(tài)發(fā)生改變時，通知Scene哪一個圖層發(fā)生變化。Scene將該圖層所在區(qū)域收集入更新區(qū)域列表，同時通知畫布進行更新。畫布更新時，只重新繪制Scene更新區(qū)域列表中的區(qū)域塊。而要游戲界面實現中，使用后一種方式，Scene收到界面更新通知時，只收集更新區(qū)域，而不再通知Canvas進4亍更新。Canvas每次更新時仍重繪Scene更新區(qū)域列表中的部分。對于2)更新方式，Canvas主動更新時序圖與圖5類似，只是Scene不再通知Canvas更新，而由Canvas發(fā)起更新操:作。在游戲軟件中多數采用主動更新的策略。本發(fā)明中針對混和器(Mixer)的界面圖層與繪制引擎接口設計方法為混和器由混和器工廠在程序中自動生成，依據有三要素a)圖像或文字元素，b)畫布，c)混和才莫式。在系統中所有混和器對象均使用單件模式?？丶揽坎倏v圖層將自己顯示在畫布上，圖層通過調用引擎層的對象實現繪制。圖層使用引擎層最基本的動作是圖像繪制和文字繪制。請參閱圖6所示，用戶(在這里是構成控件的圖層)首先使用圖象工廠(ImageFactory)創(chuàng)建圖像對象，然后根據圖像對象的格式、畫布對象的格式、混和模式創(chuàng)建出混和器，最后使用混和器根據設定的混和參數將圖像對象繪制到畫布對象上。請參閱圖7所示，在畫布上繪制文字時，首先使用文本工廠(TextFactory)生成文字對象，然后根據文字對象格式、畫布對象格式、混和模式生成混和器對象，接著用戶使用混和器對象將文字對象繪制到畫布對象中，在混和過程中，首先根據混和參數里的字體信息從字體工廠(FontFactory)獲得字體對象，然后^f吏用字體對象和混和參數進行繪制。Mixer技術為界面庫在游？3i行擴展的可能。這時混和器相當于一個特效插件。當某個圖層需要特效繪制時，只需要增加mixer對象的種類，并在MixerFactory(混合器工廠)中適當添加代碼就可以滿足需求，而且這些操作不會影響使用這套接口的其它程序?？傊鲜鏊枋龅膸追N實施方式，并不代表本發(fā)明所有的實現方式；以上實施例不是對本發(fā)明的具體限定，所有與本發(fā)明技術方案相類似的界面庫架構，都應屬于本發(fā)明的保護范圍。權利要求1、一種界面庫架構方法，其特征在于，自上而下依次包括了用戶層，控件層，場景幻燈片層和引擎層；所述用戶層通過創(chuàng)建控件層對象和調用控件層接口操縱界面元素；所述控件層包括了所有獨立控件或組合控件，控件操作場景幻燈片層的場景對象和圖層；所述場景幻燈片層包括了場景對象和圖層，場景對象管理控件圖層的繪制及更新，圖層調用引擎層的繪制引擎接口將圖層繪制在控件的畫布上；所述繪制引擎層包括了繪制引擎接口，接受來自場景幻燈片層的圖層的調用，實現圖像和文字的繪制。2、根據權利要求1所述的界面庫架構方法，其特征在于，所述的控件層以一個頂層窗口體系為一個基本管理單位，在體系中以一棵樹描述體系中所有控件的父子關系，樹上的每一個結點為一個控件。3、根據權利要求2所述的界面庫架構方法，其特征在于，所述控件包括了有窗口句柄的控件和無窗口句柄的控件；所述有窗口句柄的控件由用戶層的用戶創(chuàng)建后，生成窗口畫布并創(chuàng)建相應的場景對象；所述無窗口句柄的控件由用戶層的用戶創(chuàng)建后，使用父控件的畫布和場景對象，或者由用戶層的用戶^:置該控件的畫布和場景對象；所述場景對象管理該控件圖層以及該控件的無窗口句柄子控件圖層的繪制及更新。4、根據權利要求2所述的界面庫架構方法，其特征在于，所述控件包括了可見控件和不可見控件；所述不可見控件用于控制多個邏輯相關的控件；所述可見控件包含一個多狀態(tài)背景層，所述背景層由一個背景層工廠根據背景圖片的4并接方式創(chuàng)建。5、根據權利要求1所述的界面庫架構方法，其特征在于，所述場景幻燈片層中的場景對象使用線性列表結構保存每個圖層在此場景上的位置信息。6、根據權利要求5所述的界面庫架構方法，其特征在于，所述控件層的狀態(tài)發(fā)生改變時，通知場景幻燈片層；場景對象將該圖層所在區(qū)域收集入更新區(qū)域列表，并通知畫布進行更新。7、根據權利要求5所述的界面庫架構方法，其特征在于，所述控件層的狀態(tài)發(fā)生改變時，通知場景幻燈片層；場景對象將該圖層所在區(qū)域收集入更新區(qū)域列表；場景對象利用CPU空閑或定時器定時更新畫布。8、根據權利要求1所述的界面庫架構方法，其特征在于，所述繪制引擎層繪制圖像時，先使用圖像工廠創(chuàng)建圖像對象，并根據圖像對象的格式、畫布對象的格式、混和模式創(chuàng)建混和器，混和器根據設定的混和參數將圖像對象繪制到畫布對象上。9、根據權利要求1所述的界面庫架構方法，其特征在于，所述繪制引擎層繪制文字時，先使用文本工廠生成文字對象，并根據文字對象格式、畫布對象格式、混和模式生成混和器對象，混和器對象將文字對象繪制到畫布對象中。10、根據權利要求1所述的界面庫架構方法，其特征在于，所述控件層包括可見控件和不可見控件；所述不可見控件用于控制多個邏輯相關的控件；所述可見控件包含一個多狀態(tài)背景層，所述背景層由一個背景層工廠根據背景圖片的拼接方式創(chuàng)建。全文摘要本發(fā)明屬于軟件開發(fā)庫領域，公開了一種界面庫架構方法，其特征在于，自上而下依次包括了用戶層，控件層，場景幻燈片層和引擎層；用戶層通過創(chuàng)建控件層對象和調用控件層接口操縱界面元素；控件層包括了所有獨立控件或組合控件，控件操作場景幻燈片層的場景對象和圖層；場景幻燈片層包括了場景對象和圖層，場景對象管理控件圖層的繪制及更新，圖層調用引擎層的繪制引擎接口將圖層繪制在控件的畫布上；繪制引擎層包括了繪制引擎接口，接受來自場景幻燈片層的圖層的調用，實現圖像和文字的繪制。實施本發(fā)明的界面庫架構方法，能很好地滿足桌面網絡游戲軟件的界面需求，組件維護也非常方便。文檔編號G06F9/44GK101216762SQ20071030808公開日2008年7月9日申請日期2007年12月29日優(yōu)先權日2007年12月29日發(fā)明者燕杭申請人:騰訊科技(深圳)有限公司