在發(fā)明涉及圖像顯示處理領域，尤其涉及一種在用戶界面UI(User Interface)中圖像繪制的方法及裝置和電視。

背景技術：

HTML5(英文全稱Hyper Text Markup Language 5，中文：超文本標記語言版本5)標準給Web前端帶來了革命性的變化，大大提高了網(wǎng)頁展示豐富性和交互性。而瀏覽器引擎所具備的跨平臺性以及JavaScript腳本方便的開發(fā)調(diào)試特性，使得Web前端技術已不僅僅用于網(wǎng)頁的開發(fā)，在移動端和智能設備中也成為前端開發(fā)的一個優(yōu)先選擇。隨著HTML5標準逐漸成為主流，在智能電視UI(英文：User Interface，中文：用戶界面)領域，越來越多的廠商開始采用基于瀏覽器的Web UI開發(fā)模式。

Canvas(中文：圖形容器或畫布)是HTML5標準中一個新的標簽，它提供的繪圖API(英文：Application Programming Interface,中文：應用程序編程接口)能夠直接調(diào)用GPU(英文：Graphics Processing Unit，中文：圖形處理器)資源，實現(xiàn)圖像繪制的硬件加速，大幅提高網(wǎng)頁的圖像處理性能。但Canvas僅提供基礎的繪圖API，并不支持HTML DOM(英文：Document Object Model，中文：文檔對象模型)和CSS(英文：Cascading Style Sheets，中文：層疊樣式表)等布局管理和控制的機制，需要開發(fā)者自己去實現(xiàn)。Canvas本身并沒有UI的概念，相當于一個可以用JavaScript操作的位圖，且CSS等HTML DOM特性并不適用于Canvas，所以Canvas UI的結構，交互邏輯等需要完全由UI開發(fā)者控制，所以組件、元素以及動畫的繪制也需要開發(fā)者實現(xiàn)。由于Canvas提供的繪圖API非?；A和原始，這給UI的繪制帶來的一定的難度。UI組件基本由圖片和文字組成。對于UI來說，需要用戶察覺當前正在操作的界面，如二級菜單，彈出對話框等場景，所以界面的層級設計是不可避免的，如圖1所示場景，從Layer1(層1)界面中選擇Menu1(菜單1)，會在Layer1的基礎上打開Layer2界面，而在Layer2界面中點擊Sub Menu1，又會彈出一個確認對話框(confirm box)即Layer3。也就是說在這個場景中，Layer1、Layer2、Layer3會同時被繪制在UI界面中。根據(jù)該場景，可知其層級之間和層級中的組件之間的結構關系，形成一個渲染樹。如圖2所示，在UI進行每一幀的刷新時，需要遍歷UI root(根目錄)下的渲染樹，對每一個組件按照層的順序逐個進行繪制，最終形成反饋給用戶的整體UI界面。另外，對于每一個組件來說，又如圖3所示，展示的UI列表元素組件，通常是由背景，圖標，文字等基本元素組成的，UI在進行繪制的時候，也需要對其內(nèi)部的基本元素進行逐個繪制，從而完成一個組件的繪制。結合圖2和圖3時，也就是說，圖2所示的渲染樹結構的葉節(jié)點，實際上還有各自的子節(jié)點，從而形成一個完整的UI渲染樹。

在UI中進行繪制時，按照現(xiàn)有常規(guī)的實現(xiàn)方式，需要對整個UI渲染樹進行遍歷，并從子節(jié)點開始，逐節(jié)點進行繪制。對于渲染引擎來說，性能方面的壓力較大，在處理用戶交互的時候，容易出現(xiàn)卡頓等現(xiàn)象致使UI流暢度不好，影響用戶體驗。

技術實現(xiàn)要素：

本發(fā)明的實施例提供一種在用戶界面UI中圖像繪制的方法及裝置和電視，能夠降低圖像渲染消耗的性能，提高UI流暢度。

為達到上述目的，本發(fā)明的實施例采用如下技術方案：

第一方面，提供一種在UI中圖像繪制的方法，包括：

在渲染樹中確定待繪制的UI容器節(jié)點；

將所述待繪制的UI容器節(jié)點對應的隱藏的圖形容器Canvas的對象繪制在用戶界面UI上，其中所述隱藏的Canvas中預先繪制有所述待繪制的UI容器節(jié)點的內(nèi)容。

第二方面，提供一種在UI中圖像繪制的裝置，

遍歷單元，用于在渲染樹中確定待繪制的UI容器節(jié)點；

處理單元，用于將所述遍歷單元確定的待繪制的UI容器節(jié)點對應的隱藏的圖形容器Canvas的對象繪制在用戶界面UI上，其中所述隱藏的Canvas中預先繪制有所述待繪制的UI容器節(jié)點的內(nèi)容。

第三方面，提供一種電視，包含上述任一在UI中圖像繪制的裝置。上述方案提供的在用戶界面UI中圖像繪制的方法及裝置和電視，首先在渲染樹中確定待繪制的UI容器節(jié)點；然后將待繪制的UI容器節(jié)點對應的隱藏的圖形容器Canvas的對象繪制在用戶界面UI上。由于隱藏的Canvas中預先繪制有待繪制的UI容器節(jié)點的內(nèi)容，因此在UI進行渲染樹的遍歷并繪制到上述的待繪制的UI用戶界面容器節(jié)點的時候，由于該UI用戶界面容器節(jié)點的內(nèi)容已經(jīng)繪制到一個隱藏的Canvas中了，所以可以直接將這個隱藏的Canvas繪制到UI上。這樣，就避免的對于該待繪制的UI容器節(jié)點的大量繪制過程，降低圖像渲染消耗的性能，提高UI流暢度。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1為現(xiàn)有技術提供的一種UI場景示意圖；

圖2為現(xiàn)有技術提供的一種UI的渲染樹示意圖；

圖3為現(xiàn)有技術提供的另一種UI場景示意圖；

圖4為本發(fā)明的實施例提供的在一種在UI中圖像繪制的方法流程示意圖；

圖5為本發(fā)明的另一實施例提供的一種在UI中圖像繪制的方法流程示意圖；

圖6為本發(fā)明的實施例提供的一種UI場景示意圖；

圖7為本發(fā)明的實施例提供的一種UI的渲染樹示意圖；

圖8為本發(fā)明的實施例提供的一種在UI中圖像繪制的裝置結構示意圖。

具體實施方式

下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。基于本發(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

需要說明的是，本發(fā)明實施例中，“示例性的”或者“例如”等詞用于表示作例子、例證或說明。本發(fā)明實施例中被描述為“示例性的”或者“例如”的任何實施例或設計方案不應被解釋為比其它實施例或設計方案更優(yōu)選或更具優(yōu)勢。確切而言，使用“示例性的”或者“例如”等詞旨在以具體方式呈現(xiàn)相關概念?！暗?英文：of)”，“相應的(英文：corresponding，relevant)”和“對應的(英文：corresponding)”有時可以混用，應當指出的是，在不強調(diào)其區(qū)別時，其所要表達的含義是一致的。本方案中的”A和/或B”,指保護的方案“A”或者方案“B”或者方案“A與B”三種情況。

本發(fā)明涉及到基于HTML Canvas的Web前端開發(fā)，描述了一種在UI中經(jīng)過優(yōu)化的圖像繪制的方法。根據(jù)本發(fā)明所描述的方案，在基于HTML Canvas的智能電視UI中，通過利用隱藏的Canvas進行圖像繪制的方式，將多張圖片變?yōu)橐粡埥M合圖像，而后繪制到UI界面中，提高UI對于一些復雜場景或元素的繪制效率。以圖1為例，現(xiàn)有技術中對于用戶來說，需要進行交互的層級是Layer3，在對Layer3中的組件進行操作時，Layer1和Layer2是完全靜止的。而在采用本申請的實施例提供的方案中對于這種完全靜態(tài)的層級，我們可以考慮是否能夠?qū)⑵溥M行緩存，以及緩存后的圖像如何能夠繪制到UI界面中。相比多張圖片順序繪制的方式，本發(fā)明所描述的方案的優(yōu)點在于：復雜的UI場景或元素本身已經(jīng)比較消耗性能，同時進行大量的圖像渲染的計算，會增加CPU/GPU的負擔。在智能電視這種硬件性能資源相對有限嵌入式系統(tǒng)設備中，往往會導致UI出現(xiàn)卡頓，反應慢等現(xiàn)象，影響用戶體驗。而本發(fā)明采用的這種經(jīng)過優(yōu)化的圖像繪制方式，針對復雜的UI場景，能夠減少圖像渲染所消耗的性能，最大程度保證UI的流暢度。

具體的參照以下實施例對本發(fā)明保護的方案做具體說明：

參照圖4所示，本發(fā)明的實施例提供一種在UI中圖像繪制的方法，包括如下步驟：

101、在渲染樹中確定待繪制的UI容器節(jié)點。

102、將待繪制的UI容器節(jié)點對應的隱藏的圖形容器Canvas的對象繪制在用戶界面UI上。

其中，隱藏的Canvas中預先繪制有待繪制的UI容器節(jié)點的內(nèi)容。其中，在執(zhí)行該方法之前，需要預先為待繪制的UI用戶界面容器節(jié)點創(chuàng)建一個隱藏的圖形容器Canvas。其中，UI容器的類型包括UI層級、UI組件；具體的，可以使用document.createElement方法在內(nèi)存中創(chuàng)建一個Canvas標簽，其大小等于該待繪制的UI容器節(jié)點對象的大小。將this.cached指向這個Canvas標簽對象。在Canvas上下文提供的API中，關于圖像繪制的接口是context.drawImage(img,x,y)；這個方法的img參數(shù)，也就是需要進行繪制的對象可以傳入img標簽，video標簽或canvas標簽。也就是說，在一個HTML5Canvas中可以繪制另一個HTML5Canvas的內(nèi)容。利用這個特性，就可以為某個靜態(tài)的UI容器節(jié)點在內(nèi)存中創(chuàng)建一個隱藏的Canvas。

上述方案提供的在用戶界面UI中圖像繪制的方法，首先在渲染樹中確定待繪制的UI容器節(jié)點；然后將待繪制的UI容器節(jié)點對應的隱藏的圖形容器Canvas的對象繪制在用戶界面UI上。由于隱藏的Canvas中預先繪制有待繪制的UI容器節(jié)點的內(nèi)容，因此在UI進行渲染樹的遍歷并繪制到上述的待繪制的UI用戶界面容器節(jié)點的時候，由于該UI用戶界面容器節(jié)點的內(nèi)容已經(jīng)繪制到一個隱藏的Canvas中了，所以可以直接將這個隱藏的Canvas繪制到UI上。這樣，就避免的對于該待繪制的UI容器節(jié)點的大量繪制過程，降低圖像渲染消耗的性能，提高UI流暢度。

在為某個靜態(tài)的UI容器節(jié)點在內(nèi)存中創(chuàng)建一個隱藏的Canvas，對UI層級，組件等容器類型增加一個.cache()方法和一個.uncache()方法，并增加一個屬性cached。cache方法調(diào)用后會把該UI容器節(jié)點的層級中的所有元素繪制到一個隱藏的Canvas中，并將cached屬性指向這個隱藏的Canvas。而uncache方法會將cached屬性置空。這樣，在UI進行整體渲染的時候，如果待繪制的UI容器節(jié)點的cached屬性不為空的情況下，說明這個層級或組件已經(jīng)繪制到隱藏的Canvas中，相當于進行了預渲染。這時，UI可以無需再遍歷其子節(jié)點進行繪制，而可以直接將這個隱藏Canvas(也就是cached屬性指向的對象)繪制出來即可?；谏鲜鲈碓谏鲜霾襟E101之前還需要將待繪制的UI容器節(jié)點的內(nèi)容預先繪制在隱藏的Canvas中，參考如圖5所示的流程，具體如下：

201、判斷待繪制的UI容器節(jié)點是否存在子節(jié)點。

步驟201之前，需要預先為待繪制的UI用戶界面容器節(jié)點創(chuàng)建一個隱藏的圖形容器Canvas。具體的，使用document.createElement方法在內(nèi)存中創(chuàng)建一個Canvas標簽，其大小等于該待繪制的UI容器節(jié)點對象的大小。將this.cached指向這個Canvas標簽對象。

202、當確定待繪制的UI容器節(jié)點包含子節(jié)點時，判斷待繪制的UI容器節(jié)點的緩存cached屬性是否為空。

203、當確定cached屬性不為空時，將UI容器節(jié)點中cached屬性指向的隱藏Canvas對象繪制到隱藏的Canvas上。

如果不為空，說明該UI容器節(jié)點已經(jīng)被緩存，則調(diào)用context.drawImage方法將該UI容器節(jié)點的cached屬性指向的隱藏Canvas對象繪制到隱藏的Canvas上。

204、當確定待繪制的UI容器節(jié)點不包含子節(jié)點時，確定該待繪制的UI容器節(jié)點是否包含圖片或文字。

205、當確定待繪制的UI容器節(jié)點為圖片時，將圖片繪制到隱藏的Canvas中。

206、當確定預定UI容器節(jié)點為文字時，將文字繪制到隱藏的Canvas中。

在步驟204-206中，如果該UI容器節(jié)點沒有子節(jié)點，則說明該UI容器節(jié)點中的對象是基本的圖片元素或文字，并不是容器類型，所以不可能具有cached屬性。故調(diào)用context.drawImage或context.fillText方法，將圖片或文字繪制到this.cached指向的Canvas對象中。

207、當確定cached屬性為空時，將預定UI容器節(jié)點的子節(jié)點的內(nèi)容繪制在另一隱藏的Canvas中。

而uncache方法的實現(xiàn)步驟則是將容器對象的.cached屬性置為空。此時，切斷了指向隱藏Canvas的指針，該隱藏Canvas將在適合的時機，通過瀏覽器JavaScript的垃圾回收機制銷毀。

循環(huán)執(zhí)行步驟202、207遍歷該UI容器節(jié)點的所有子節(jié)點，具體的針對子節(jié)點，創(chuàng)建對應每個子節(jié)點的對象大小的隱藏的Canvas，并分別將子節(jié)點繪制到對應隱藏的Canvas中。

208、遍歷待繪制的UI容器節(jié)點所屬渲染樹中的節(jié)點，將渲染樹中所有UI容器節(jié)點繪制到對應的隱藏的Canvas上。

完成上述步驟201至208后便可以對渲染樹中的所有UI容器節(jié)點進行渲染繪制到UI當中，在UI進行整體渲染的時候，如果待繪制的UI容器節(jié)點的cached屬性不為空的情況下，說明這個層級或組件已經(jīng)繪制到隱藏Canvas中，相當于進行了預渲染。這時，UI可以無需再遍歷其子節(jié)點進行繪制，而可以直接將這個隱藏的Canvas(也就是cached屬性指向的Canvas)繪制出來即可。

如按照圖3例舉的場景，該UI組件由多個元素組成，常規(guī)方式需要在每次刷新的時候分別渲染其內(nèi)部的各個元素。其渲染樹如圖6所示，列表項(List Item)之下包含：背景(Background)，圖標(Icon)，標題文本(Title Text)，詳細文本(Detail Text)以及箭頭記號(Arrow)。但從組件的角度來說，其內(nèi)部元素是固定靜止的，故可以調(diào)用該組件的cache對象，將其進行緩存。這樣，該組件在被渲染時，只需進行一次渲染處理，就完成了該組件的繪制。而實際應用時，這樣的組件有很多，采用這種隱藏的Canvas緩存的方式，可以大大減輕渲染引擎的負擔，提高UI的流暢度。另如按照圖2例舉的場景，在UI需要渲染一幀的時候，此時UI中的Layer1和Layer2為靜止狀態(tài)，用戶的操作僅對Layer3起作用。這種場景，我們就可以對Layer1和Layer2調(diào)用cache方法，將這兩個層級緩存至隱藏的Canvas。那么UI需要遍歷的渲染樹就變成如下圖7所示，UI渲染界面的流程其實和圖5所示流程是一樣的，在此不再贅述。UI在進行用戶交互的時候，或在處理動畫效果的時候，為了給用戶流暢的體驗，需要每秒進行UI刷新的次數(shù)至少為24幀。而如果使用常規(guī)方式遍歷整個樹結構進行渲染，則每一幀都需要對所有的節(jié)點進行繪制。而圖7與圖2相對比可以明顯看到，每一幀需要渲染的節(jié)點大大減少。這時，渲染引擎就能夠在每一秒渲染更多的幀，使用戶體驗更為流暢。另外，HTML5Canvas對于文字的處理能力并不強，文字的渲染相對于圖片來說是非常耗費性能資源的。將文字繪制到隱藏Canvas中，相當于把文字轉(zhuǎn)換為圖片，再將隱藏Canvas繪制到UI界面上，可以規(guī)避Canvas的文字渲染這個弱項，加快渲染速度。

至此，通過以上步驟，利用Canvas提供的API的特性，對圖片和文字元素進行隱藏Canvas的預渲染，實現(xiàn)了類似圖像緩存的功能。在UI每一幀的渲染的過程中，規(guī)避了大量靜止元素的重復渲染，降低UI對性能的消耗。特別是在相對復雜的場景中，這種繪制方式能夠有效的解決UI的卡頓現(xiàn)象，給用戶帶來良好的交互體驗。

參照圖8所示，本發(fā)明的實施例提供一種在UI中圖像繪制的裝置，包括：

遍歷單元81，用于在渲染樹中確定待繪制的UI容器節(jié)點；

處理單元82，用于將所述遍歷單元確定的待繪制的UI容器節(jié)點對應的隱藏的圖形容器Canvas的對象繪制在用戶界面UI上，其中所述隱藏的Canvas中預先繪制有所述待繪制的UI容器節(jié)點的內(nèi)容。

可選的，所述處理單元82還用于為所述待繪制的UI容器節(jié)點創(chuàng)建所述隱藏的Canvas；將所述待繪制的UI容器節(jié)點的內(nèi)容繪制在所述隱藏的Canvas中。

可選的，所述處理單元82具體用于判斷所述待繪制的UI容器節(jié)點是否存在子節(jié)點；當確定所述待繪制的UI容器節(jié)點包含子節(jié)點時，判斷所述待繪制的UI容器節(jié)點的緩存cached屬性是否為空；當確定所述cached屬性不為空時，將所述待繪制的UI容器節(jié)點中cached屬性指向的隱藏Canvas對象繪制到所述隱藏的Canvas上。

可選的，所述處理單元82具體用于當確定所述待繪制的UI容器節(jié)點不包含子節(jié)點時，判斷該待繪制的UI容器節(jié)點的組件為圖片或文字；當確定所述待繪制的UI容器節(jié)點為圖片或文字時，將所述圖片或文字繪制到所述隱藏的Canvas中。

可選的，所述處理單元82具體用于當確定所述cached屬性為空時，將所述待繪制的UI容器節(jié)點的子節(jié)點的內(nèi)容繪制在另一隱藏的Canvas上。

上述方案提供的在用戶界面UI中圖像繪制的裝置，首先在渲染樹中確定待繪制的UI容器節(jié)點；然后將待繪制的UI容器節(jié)點對應的隱藏的圖形容器Canvas的對象繪制在用戶界面UI上。由于隱藏的Canvas中預先繪制有待繪制的UI容器節(jié)點的內(nèi)容，因此在UI進行渲染樹的遍歷并繪制到上述的待繪制的UI用戶界面容器節(jié)點的時候，由于該UI用戶界面容器節(jié)點的內(nèi)容已經(jīng)繪制到一個隱藏的Canvas中了，所以可以直接將這個隱藏的Canvas繪制到UI上。這樣，就避免的對于該待繪制的UI容器節(jié)點的大量繪制過程，降低圖像渲染消耗的性能，提高UI流暢度。

其中，本發(fā)明的實施例還提供一種電視，包含上述任一實施例提供的在UI中圖像繪制的裝置。

需要說明的是，在具體實現(xiàn)過程中，上述如圖4、5所示的方法流程中UI中圖像繪制的裝置所執(zhí)行的各步驟均可以通過硬件形式的處理器執(zhí)行存儲器中存儲的軟件形式的計算機執(zhí)行指令實現(xiàn)，為避免重復，此處不再贅述。而上述UI中圖像繪制的裝置所執(zhí)行的動作所對應的程序均可以以軟件形式存儲于該UI中圖像繪制的裝置的存儲器中，以便于處理器調(diào)用執(zhí)行以上各個模塊對應的操作。

上文中的存儲器可以包括易失性存儲器(volatile memory)，例如隨機存取存儲器(random-access memory，RAM)；也可以包括非易失性存儲器(non-volatile memory)，例如只讀存儲器(read-only memory，ROM)，快閃存儲器(flash memory)，硬盤(hard disk drive，HDD)或固態(tài)硬盤(solid-state drive，SSD)；還可以包括上述種類的存儲器的組合。

上文所提供的裝置中的處理器可以是一個處理器，也可以是多個處理元件的統(tǒng)稱。例如，處理器可以為中央處理器(central processing unit，CPU；也可以為其他通用處理器、數(shù)字信號處理器(digital signal processing，DSP)、專用集成電路(application specific integrated circuit，ASIC)、現(xiàn)場可編程門陣列(field-programmable gate array，F(xiàn)PGA)或者其他可編程邏輯器件、分立門或者晶體管邏輯器件、分立硬件組件等。通用處理器可以是微處理器或者該處理器也可以是任何常規(guī)的處理器等；還可以為專用處理器，該專用處理器可以包括基帶處理芯片、射頻處理芯片等中的至少一個。

所屬領域的技術人員可以清楚地了解到，為描述的方便和簡潔，上述描述的裝置和模塊的具體工作過程，可以參考前述方法實施例中的對應過程，在此不再贅述。

在本申請所提供的幾個實施例中，應該理解到，所揭露的裝置和方法，可以通過其它的方式實現(xiàn)。例如，以上所描述的裝置實施例僅僅是示意性的，例如，所述模塊的劃分，僅僅為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式，例如多個模塊或組件可以結合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，裝置或單元的間接耦合或通信連接，可以是電性，機械或其它的形式。

所述作為分離部件說明的模塊可以是或者也可以不是物理上分開的，作為模塊顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。

另外，在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理包括，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現(xiàn)，也可以采用硬件加軟件功能單元的形式實現(xiàn)。

以上所述，以上實施例僅用以說明本申請的技術方案，而非對其限制；盡管參照前述實施例對本申請進行了詳細的說明，本領域的普通技術人員應當理解：其依然可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替換；而這些修改或者替換，并不使相應技術方案的本質(zhì)脫離本申請各實施例技術方案的精神和范圍。