本主題一開始將對 SVG 與 Canvas 進行簡要比較,接下來會討論大量的比較代碼示例,如光線跟蹤和綠屏。 javascript
注意 爲了查看本主題中包含的不少示例,你必須使用支持 SVG 和 Canvas 元素的瀏覽器(如 Windows Internet Explorer 9)。 css
HTML 不斷演變以提供更好、更豐富的標準圖形來幫助改進客戶體驗。 爲 Web 開發人員創造了使用基於標準的 Web 技術建立圖形豐富的交互網站和應用程序的機會,而無需使用專用的技術或編寫瀏覽器特定的代碼。如下各節介紹了向量圖形的概念並執行相應操做: html
向量圖形不是新概念。它們是所有基於向量來表示圖像的幾何基元(形狀、點、線條和多邊形)。在 1960 年代後期,向 Logo 編程語言添加了向量圖形語言(海龜繪圖)來支持用於執行繪圖功能的海龜機器人。雖然圖形世界在複雜性方面已經發生了重大的演變,可是存在的基本概念是相同的。 前端
向量圖形的複雜性範圍從簡單到適中再到至關複雜。下面是一些基本示例。 java
儘管前面的示例在性質上是靜態的,可是向量圖形也支持交互性,這是一項可顯著擴展方案的關鍵功能。向量圖形爲 Web、桌面和設備上的應用程序提供交互和靜態的格式。 ios
專業的 Web 設計人員在以下工具集中查看向量圖形: 算法
請務必注意,向量圖形已經在桌面、設備和 Web 上存在很長時間了。 數據庫
藉助 HTML5,開發人員或設計人員如今可使用基於標準的技術來建立之前的體驗。這樣可消除對插件的安裝(50% 的網站放棄訪問均與插件的安裝相關),從而能夠極大地改善用戶體驗。目前,圖形由瀏覽器原生提供,而對於 Internet Explorer 9,則利用 Microsoft Windows 和硬件加速圖形的功能。 編程
下一節概述了兩種全新但不一樣的技術、這兩種技術的使用方法以及各自的優點和限制。使用一個向量圖形方案譜表來討論用於爲每一個方案選擇最佳技術的方法。 canvas
下圖顯示了存在於向量圖形中的一個常規方案譜表。每個方案均可能會更接近於 canvas 或 svg,這意味着一種技術相對於其餘技術更適合該方案。若是方案位於譜表中間,那麼選擇任一技術都是可行的
幾乎全部向量圖形均可以使用上述任一種技術來繪製,但有時根據任務的不一樣,會有很是多的工做要由開發人員或計算機完成。 當咱們檢查每種技術的用例,而後將其應用於常見方案時,咱們會進一步瞭解此譜表。
下一節介紹了用於在 HTML5 中建立向量圖形的技術,從而創建對早期存在的方案的討論。
若要使用如下示例,請將如下代碼示例用做模板。可使用此模板來開發 SVG 而非 HTML。此模板在本主題的每一個示例中使用。因爲格式緣由,你可使用腳本以及樣式。此模板還包含一個 Meta 標記,這使得能夠在本地文件共享上更輕鬆地進行 SVG 開發。這些示例使用下面的格式。首先提供有意義的代碼,而後連接到完整代碼。
<!DOCTYPE html > <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="X-UA-Compatible" content="IE=9"/> <style type="text/css" media="screen"> </style> <script type="text/javascript"> </script> </head> <body> </body> </html>
http://samples.msdn.microsoft.com/workshop/samples/graphicsInHTML5/template.htm (單擊「查看源文件」便可查看此標記)。
SVG 用於描述可縮放向量圖形,這是一個保留在內存中模型中的保留模式圖形模型,而內存中模型可經過從新呈現的代碼結果進行操做。這不一樣於即時模式,該模式將稍後討論。在 HTML5 中同時提供這兩種模式。
SVG 是一個保留模式模型,做爲對獨立供應商(Microsoft 和 Adobe)所提出的兩個建議的迴應,在 1999 年引入。成立了 W3C SVG 工做組,而且在 2001 年 SVG 規範達到了「建議的狀態」。目前,咱們按照 SVG 1.1 第 2 版工做,該版本在編寫本文時處於「最後徵求意見」階段。
儘管 SVG 能夠做爲獨立文件進行提供,可是最初着重於將它與 HTML 天然集成。
相似於 HTML,SVG 也是使用元素、屬性、和樣式來構建文檔。首次將 <svg> 元素引入到文檔中時,該元素的行爲很是相似於 <div> 且做爲 HTMLDocument 的一部分,但它包含附加接口 SVGDocument(SVGDocument 提供與向量圖形的更深刻、更豐富的交互)。
儘管外部 <svg> 包裝適合於 HTML 框模型,可是大多數狀況下,內部模型都會從該包裝中分離出來,由於向量不侷限於簡單的框。這種分離要求擴展 SVG 中的屬性才能提供豐富的圖形。
例如:
<svg height="1000px" width="1000px"> <rect id="myRect" height="100px" width="100px" fill="blue"/> </svg>
http://samples.msdn.microsoft.com/workshop/samples/graphicsInHTML5/bluerect.htm
注意 爲了呈現此內容以及如下不少示例,你必須使用支持 SVG 和 Canvas 元素的瀏覽器(如 Internet Explorer 9)。
以前的 HTML 代碼將建立一個正方形,長寬均爲 100 像素,並使用藍色背景進行填充。
此 <rect> 元素保留在 HTML 文檔的文檔對象模型 (DOM) 中。就像其餘 HTML 元素同樣,可經過多種不一樣的方式設置 SVG 的樣式。下面的示例是一個表。
開發人員可能會注意到屬性是相似的。SVG 同時具備屬性和演示屬性。此處看起來描述有點隨意,但關鍵在於能夠按照 CSS 樣式規則設置演示屬性的樣式。
四個矩形使用幾種不一樣的方法進行填充。
<!--No fill (defaults the color to #000000)--> <rect id="myRect1" height="100%" width="100%" > <!--using the class="greenrect"--> <rect id="myRect2" height="100%" width="100%" class="greenrect"/> <!--using the style="fill:pink"--> <rect id="myRect3" height="100%" width="100%" style="fill:pink"/> <!--using the attribute fill="red"--> <rect id="myRect4" height="100%" width="100%" fill="red"/>
第一個示例演示省去一個屬性會在圖形上產生可視效果。在此示例中,顏色默認爲黑色。
第二個示例演示使用 class="greenrect" 來填充矩形。包含的用於填充此矩形的 CSS 的形式爲:
rect.greenrect {fill:green;}
第三個示例使用內聯樣式將填充設置爲粉色。最後一個示例使用相應屬性填充紅色。此示例還演示了 CSS 選擇器的用法。樣式還包括:
rect:hover {fill:yellow;}
這針對全部矩形創建一個規則,即鼠標懸停在這些矩形之上時顏色更改成黃色。
這些對於有經驗的 Web 開發人員來講應該都不是新內容了。此處提供這些示例是爲了強調類似性(使用樣式、樣式表、類和選擇器)以及差別(樣式不適用於全部屬性,僅適用於演示屬性、新屬性或不一致的屬性)。
http://samples.msdn.microsoft.com/workshop/samples/graphicsInHTML5/svgstyling.htm
屬性 API 及其餘 DOM 操做仍應用並遵循當前的屬性規則。例外狀況是,演示應用程序基於樣式所取代的屬性(若是適用)。
若是這些屬性是經過核心屬性或經過其各自的 DOM 方法進行設置的,則將影響這些屬性的演示,而且基礎 DOM 將相應地發生更改(注意使用 SVG DOM 設置高度的不一樣語法):
document.getElementById("myDiv").style.height = "200px"; // alternatively //document.getElementById("myDiv").style="height;200px"; document.getElementById("myRect").height.baseVal.value = 200; // alternatively //document.getElementById("myRect").setAttribute("height","200px");
SVG 的另外一個關鍵區分因素是可以進行代碼交互且不復雜。正如 SVG 具備一個相似 HTML 的可編程 DOM 同樣,它還具備事件模型。檢查下面比矩形或正方形更復雜的圖形:路徑。
使用路徑可繪製任意形狀,例如在該示例中爲表示美國的阿拉斯加州和夏威夷州的兩個形狀。
http://samples.msdn.microsoft.com/workshop/samples/graphicsInHTML5/svginteractivity.htm
觸發建立以前指定的警報的事件。這些複雜形狀(像更簡單的矩形)也會響應 CSS 選擇器。使用一行 CSS 便可實現簡單的突出顯示機制:
path:hover {fill:yellow;}
另外一種向用戶提供更豐富的圖形體驗的方法,經過 <canvas> 標記提供,該標記由 Apple for Safari 在 HTML5 中或在其餘圖形小工具中引入。它在繪製即時模式圖形(包括矩形、路徑和圖像)方面公開更具編程性的體驗,與 SVG 相似。即時模式圖形呈現是一個「觸發即忘」模型,該模型將圖形直接呈現到屏幕上,但隨後對所完成的操做不保留任何上下文。與保留模式相反,不保存呈現的圖形;要在每次須要新框架時描述整個場景,開發人員須要從新調用全部必需的繪圖命令,而不考慮實際更改(SVG 已知擁有「場景圖」)。
爲了使用畫布 (Canvas) 功能,Web 開發人員直接引入了一個 Canvas 元素:
<canvas id="myCanvas" width="1200px" height="1200px"></canvas>
而後使用 <canvas> 傳統的2D基礎庫 API 來繪製圖像和向量。
使用 JavaScript 代碼執行對畫布上圖形的操做,經過添加對圖形的支持能夠得到 Web 開發人員熟悉使用的優點。
var canvas = document.getElementById("myCanvas"); var ctx = canvas.getContext("2d");
如前面提到的,存在與 SVG 中類似的形狀和對象,舉例來講,開發人員可使用下面的代碼來繪製矩形:
ctx.fillStyle = "rgb(0,0,255)";
ctx.fillRect(10, 10, 100, 100);
稍後將討論這些方法的優缺點以及適當的方案。
最終結果與在 SVG 中相同。http://samples.msdn.microsoft.com/workshop/samples/graphicsInHTML5/canvasintro.htm
但正如 SVG 同樣,Canvas 具備更復雜的幾何基元,區別在於這些基元採用函數形式。
爲了可以繪製比矩形更復雜的圖形(如前面顯示的夏威夷地圖),canvas API 提供了一個路徑 API,該路徑 API 支持與 SVG 中的 <path> 元素類似的命令,只是你要對每一行代碼段調用相應的 API,而不是在單個屬性中列出它們:
ctx.beginPath(); ctx.moveTo(233.08751,519.30948); ctx.lineTo(235.02744,515.75293); ctx.lineTo(237.29070000000002,515.42961); ctx.lineTo(237.61402,516.23791); ctx.lineTo(235.51242000000002,519.30948); ctx.lineTo(233.08751,519.30948); ctx.closePath();
有關夏威夷地圖,請參閱 http://samples.msdn.microsoft.com/workshop/samples/graphicsInHTML5/canvasmap.htm。
路徑 API 並不侷限於 moveTo 和 arc,它包含相同的 SVG 方向相位(包括二次曲線和貝塞爾曲線)。
經過有限的事件和功能能夠捕獲鼠標在圖像上的位置。由於不存在圖形保留知識,因此編程人員必須轉換 mouseX 標記的單個元素上的 mouseY、<canvas> 座標,而後將該命令相應地傳送到位於內存中結構中的形狀。第三方庫爲支持更復雜的路徑而存在,這包括內置 isPointInPath API,但後者被限制爲最後路徑繪製。於是與 SVG 不一樣,既沒有任何樣式也不支持多個幾何圖上的命中檢測。另外,由於 Canvas 不支持可伸縮性,因此縮放時夏威夷地圖將很快失真:
Canvas 是一個功能強大的低級別 API,開發人員利用它能夠提供新的圖形體驗。
下面是簡要摘要,可幫助你肯定什麼時候使用 Canvas 而不使用 SVG 或者什麼時候使用 SVG 而不使用 Canvas 來建立向量圖形。
Canvas | SVG |
---|---|
基於像素(動態 .png) | 基於形狀 |
單個 HTML 元素 | 多個圖形元素,這些元素成爲 DOM 的一部分 |
僅經過腳本修改 | 經過腳本和 CSS 修改 |
事件模型/用戶交互顆粒化 (x,y) | 事件模型/用戶交互抽象化 (rect, path) |
圖面較小時、對象數量較大 (>10k)(或同時知足這兩者)時性能更佳 | 對象數量較小 (<10k)、圖面更大(或同時知足這兩者)時性能更佳 |
在上表中,考慮這兩者在現有軟件方面的意象模型。Canvas 相似於 MSPaint,在其中,你可使用形狀和其餘工具來繪製和建立圖像。SVG 相似於 Office PowerPoint 幻燈片,它具備可編程的支持而且可以添加主題。
這一節介紹這兩種技術的技術優點和限制,包括用於肯定一種技術什麼時候相對於另外一種技術更適合的經常使用方法。應該注意的是,SVG 和 <canvas> 都能實現幾乎相同的結果,功能也徹底重複。介紹如下特定狀況很是重要:<canvas> 明顯好於 SVG,或相反,兩者組合更加合適,或可使用和考慮任一技術。
這些方案比較清晰地描述了更適合使用 SVG 的狀況、更適合使用 Canvas 的狀況,以及其餘介於這之間的狀況。它們描述了每種技術的優缺點,以便開發人員能夠了解相應技術的行爲並針對其應用程序作出好的選擇。
有時存在一些外部影響,要求獨立於(或幾乎獨立於)功能選擇技術。有關使用 Canvas 或 SVG 的問題,存在兩個主要區別。
有時開發人員的知識、技能組合和現有資產會對技術的選擇起到重大做用。若是開發人員具有低級別圖形 API 方面的深層知識,但在 Web 技術方面知識有限,則極可能會選擇 Canvas 技術。
另外,性能對於高流量的網站來講是絕對關鍵的。能夠對這兩種技術的性能特徵加以比較。這可能會要求開發 Canvas 沒有附帶的輔助功能、自定義樣式以及更粒度化的用戶交互功能。雖然 Canvas 一般被視爲具備高性能,可是並不意味着它就是明顯的選擇。下圖顯示了 SVG 對象和 Canvas 對象之間在呈現時間上的差別。
通常狀況下,隨着屏幕大小的增大,畫布將開始降級,由於須要繪製更多的像素。隨着屏幕上的對象數目增多,SVG 將開始降級,由於咱們正不斷將這些對象添加到 DOM 中。這些度量不必定準確,如下方面的不一樣必定會引發變化:實現和平臺、是否使用徹底硬件加速的圖形,以及 JavaScript 引擎的速度。
高保真度的複雜向量文檔已經成爲並將繼續成爲 SVG 的最有效點,緣由主要有兩個。存在足夠多的極爲詳細的文檔,包括由 CAD 程序生成的那些文檔,針對這些文檔,SVG 的 scalable 部分提供了獨立文檔形式或嵌入網頁中的文檔形式的詳細視圖。經過該技術還能夠進行高保真打印。SVG 的聲明性性質向工具、客戶端或服務器端提供從數據庫生成形狀的能力。 最後,咱們看到了政府機構的發展,因工程圖(爲了專利)或工業圖(爲了城市規劃目的)緣故從建議支持轉變爲對 SVG 的必需支持。這種轉變還將繼續,由於對於公衆使用的電子文檔(以下),政府部門愈來愈不是隻喜歡一家供應商:
如下各圖顯示了前一方案中能夠保留的詳細信息示例。第一個圖像顯示能夠在測試驅動網站上找到的網頁快照。它包含呼吸系統圖和元素週期表。
http://ie.microsoft.com/testdrive/Graphics/RealWorldDataAndDiagrams/Default.xhtml
第二個圖像顯示同一張圖放大 1000% 後的效果
儘管考慮到觀察大的示意圖的有用性,但在須要細化到細節處時或者出於工程目的須要打印整個示意圖時,具備可縮放性的 S 將變得足夠清晰和有價值。出於這些緣由,咱們將高保真度的複雜向量文檔放在譜表的遠端,接近 SVG,以下圖中所示。
這些文檔也能夠受益於交互性,這是 SVG 使這些方案最適合於保留圖形模式的第二方面。
SVG 另外還經常使用於簡單圖像,不管是應用程序仍是網頁中的圖像,大圖像仍是小圖像。因爲 SVG 要加載到 DOM 中,或者建立圖像前至少要進行解析,因此性能會稍微有所降低,但相比於呈現網頁的成本(大約幾毫秒),這種降低是極其微小。
在文件大小方面(爲了評估網絡流量的目的),下面演示的兩個圖像是同樣的,只差了 1K(SVG 稍微大點,沒有壓縮)。
與之前同樣,由於 SVG 做爲圖像格式是可縮放的,因此若是開發人員想要以更大的比例使用該圖像,或者用戶使用高 DPI的屏幕,則可移植網絡圖形 (PNG) 要麼會變得異常,要麼須要更大形式的文件來實現保真。
SVG 所以能夠充當很是好的圖像替換格式,甚至對網頁上最簡單的圖像也是如此。靜態 WebApp/網頁圖像所以落在譜表的 SVG 端。
在譜表的另外一端,當使用 Canvas 時能夠得到快速的繪圖速度,且不須要保留相應信息。存在若干種最適合於 <canvas> 的實時數據方案。使用光線跟蹤在像平面上經過像素跟蹤光線路徑並模擬其與虛擬對象相遇的效果,能夠水化圖像。 下圖顯示了這種模擬。
須要不少計算,所以速度依賴於瀏覽器中的 JavaScript 引擎速度。然而儘管大多數狀況下本地代碼不容置疑要更快一些,可是隨着 JavaScript 引擎逐漸成熟,咱們開始看到在像程序集和 C++ 這樣的時期內這種差距在縮小。
光線跟蹤(一般在 Web 上的背景中完成)得到的效果甚爲普遍。範圍從建立許多不一樣的視覺效果(包括根據其餘簡單向量圖形建立逼真的圖像)到應用照片過濾器以去除紅眼。
由於 Canvas API 容許開發人員讀寫像素,因此這裏惟一的限制是速度和想象力。上一個示例由 Adam Burmister 提供而且位於 http://labs.flog.co.nz/raytracer/上。 在此示例中,可經過大量的庫來實現建立最終圖像所需的計算,但主結束函數是 fillRect。
setPixel: function(x, y, color){ var pxW, pxH; pxW = this.options.pixelWidth; pxH = this.options.pixelHeight; this.canvas.fillStyle = color.toString(); this.canvas.fillRect (x * pxW, y * pxH, pxW, pxH); },
出於此緣由,高性能圖形(如光線跟蹤器)做爲 Canvas 方案落在譜表的最左端,以下圖所示。
注意生成上述光線跟蹤器的做者 注意 由於該方案將產生靜態圖像,因此桌面軟件通過了很好的調整以適合光線跟蹤器所需的大量浮動操做。
下至金屬像素操做的有趣實現是圖像的過濾器應用。過濾器已存在於 Web 上,且須要顯著的處理速度(受益於其對圖形管道中更深層的硬件加速圖形的應用),所以開發人員能夠試用邊緣檢測或其餘數學表達式等算法。
對於更常見的方案,Canvas 很是適合輸出實時數據。請注意如何簡便地肯定這些方案,由於已經代表使用 Canvas 難以進行用戶交互。所以,下面將討論非交互的實時數據可視化。
今天的天氣數據能夠經過特定間隔內服務器上生成的圖像很是靜態地呈現,也能夠儘量快地經過客戶端第三方插件呈現。儘管 ECWMF 已經研究過使用 SVG 而不使用服務器生成的圖像如何節省成本,可是 Canvas 在天氣模式(以及其餘快速的實時數據)的大多數圖形表示形式方面,明顯是贏家。下圖顯示以圖形方式顯示在地圖上的天氣模式。
如你能夠從上圖中看到的,沒有必要存在大的繪圖圖面,並且屏幕上的對象數量是至關高的。經過使用 Canvas API,能夠在不影響 DOM 的狀況下快速繪製(和擦除)這些對象。儘管可使用 SVG Ellipse 完成此操做,可是將它們加載到 DOM 中以及經過動畫修改它們的成本是很是高的。事實上,不管你是在圖像中仍是在數據動畫中看到大量的形狀(尤爲是不類似的形狀)要進行分析,一般都會指出 Canvas 是要使用的技術。這裏的實際限制是受 CPU 速度和 JavaScript 引擎速度的控制,能多快可視化顯示數據。但除了佔用 CPU 的光線跟蹤方案以外,仍然能夠實現合理的動畫。Reasonable 描述客戶端可使用 JavaScript 執行的操做與服務器能夠經過電線計算和封送的操做之間的相對動畫。
此方案彷佛是 <canvas> 的關鍵用例。
另外一個使用 Canvas 的可能狀況是,在視頻上進行顏色檢測以便用其餘場景或圖像替換背景色。像光線跟蹤器或過濾器同樣,因 JavaScript 中當前性能速度限制的緣故,極可能會使用桌面軟件預處理任何須要高的最終產品質量的現實方案。可是,因爲 <canvas> 是爲低級別像素讀取和寫入設計的,所以諸如 greenscreen 替換之類的方案甚至沒法使用 SVG 完成。
從兩個視頻中讀寫像素到另外一個視頻中所需的代碼要求使用兩個視頻、兩個畫布和一個最終畫布。一次捕捉視頻上的一幀,而後繪製到兩個單獨的畫布上。這樣容許讀回數據。
ctxSource1.drawImage(video1, 0, 0, videoWidth, videoHeight); ctxSource2.drawImage(video2, 0, 0, videoWidth, videoHeight);
所以,下一步是檢索每一個繪製圖像的句柄,以便你能夠檢查每一個單獨的像素。
currentFrameSource1 = ctxSource1.getImageData(0, 0, videoWidth, videoHeight); currentFrameSource2 = ctxSource2.getImageData(0, 0, videoWidth, videoHeight);
獲取後,代碼將瀏覽綠屏的像素數組,搜索綠色像素,若是找到,代碼將用背景場景中的像素替換全部綠色像素。
for (var i = 0; i < n; i++) { // Grab the RBG for each pixel: r = currentFrameSource1.data[i * 4 + 0]; g = currentFrameSource1.data[i * 4 + 1]; b = currentFrameSource1.data[i * 4 + 2]; // If this seems like a green pixel replace it: if ( (r >= 0 && r <= 59) && (g >= 74 && g <= 144) && (b >= 0 && b <= 56) ) // Target green is (24, 109, 21), so look around those values. { pixelIndex = i * 4; currentFrameSource1.data[pixelIndex] = currentFrameSource2.data[pixelIndex]; currentFrameSource1.data[pixelIndex + 1] = currentFrameSource2.data[pixelIndex + 1]; currentFrameSource1.data[pixelIndex + 2] = currentFrameSource2.data[pixelIndex + 2]; currentFrameSource1.data[pixelIndex + 3] = currentFrameSource2.data[pixelIndex + 3]; } }
最後,像素數組將寫入到目標畫布中。
ctxDest.putImageData(currentFrameSource1, 0, 0);
http://samples.msdn.microsoft.com/workshop/samples/graphicsInHTML5/canvasgreenscreen.htm(若要完整地查看 greenscreen 代碼,請查看該頁的源代碼。)
如下方案能夠在 SVG 或 Canvas 中完成,均可以得到適當的結果,但你可能會更喜歡一項技術賽過另外一項技術。
須要向量圖形的圖表和圖形的譜表很寬廣。大部分這些圖形最好使用 SVG 進行建立,由於它們具備下列三個特徵之一:
咱們使用可顯著增長方案範圍的交互功能來擴展高保真文檔方案。 其中包括:
已經肯定快速的實時數據處理已針對 Canvas 進行了更好地優化(主要取決於速度)。
製做休閒遊戲(此處定義爲 Web 上的簡單二維遊戲)時,開發人員須要在 canvas 和 svg 之間作出選擇。由於歷史上遊戲庫一直利用較低級別的圖形 API,因此將傾向於選擇 <canvas>。
當庫的其餘組成部分(如受歡迎的物理引擎)比圖形層要明顯深時,圖形將變成實現細節。邊框、速度、大小和位置等圖形幾何將傳遞給引擎,而引擎隨後將用速度、碰撞和位置進行響應。圖形位於堆棧中的最高層。
經過由同一做者開發的兩個遊戲來演示獨立於遊戲邏輯的圖形概念,旨在說明 <svg> 和 <canvas>:SVG-oids 和 canvas-pinball。一個出色的、獨立於遊戲引擎的圖形層示例是將 canvas-pinball 與 SVG-Dice 進行比較(當二者都使用相同的物理引擎時)。
儘管遊戲和演示邏輯是不一樣的,可是這兩個遊戲的物理引擎都會跟蹤位置、碰撞、速度以及遊戲組成部分的其餘物理方面。
對於 canvas-pinball,自定義的更高級別的動畫管理器經過使用一系列 Canvas API 從新繪製場景。
if (animationsInProgress) {
ctx.save();
ctx.lineWidth = 2.0;
ctx.beginPath();
ctx.moveTo(89, 322);
ctx.lineTo(101, 295);
.
.
.
ctx.stroke();
ctx.restore();
ctx.moveTo(tVp.x, tVp.y);
}
對於 SVG Dice,自定義的更高級別的動畫管理器使用組轉換經過 DOM 在屏幕上從新定位現有圖形。
if (animationsInProgress) { this.rotation += (this.circleBody.m_linearVelocity.x/20); var transFormString = "translate(" + Math.round(this.circleBody.m_position.x) + "," + Math.round(this.circleBody.m_position.y) + ") scale (" + this.scale.toString() + ") rotate(" + Math.round(this.rotation).toString() + "," + Math.round(this.xTrans).toString() + "," + Math.round(this.yTrans).toString() + ")"; this.die2.setAttribute("transform", transFormString); }
一種技術要從新繪製和從新定位形狀,而另外一種技術只需從新定位,但須要在內存中維護形狀,這會帶來成本。此成本對於大多數休閒遊戲來講都是至關低的,但預期是使用較低級別的 API 實現即時模式圖形的遊戲更加讓人熟悉。
可能大部分功能強大的方案都會涉及組合整個圖形、樣式和文檔技術。
幾年前可能就在爭論 SVG 是不是適合用於用戶界面設計的技術。這些要求與 SVG 一致。事實上,Linux 操做系統的至少一個前端徹底創建在 SVG 之上。滑塊、複選框、圓形按鈕等控件以及其餘標準固有控件集中的非框控件都很適合在向量圖形中使用。可是,隨着 CSS 的最近和將來開發(包括圓角、漸變、過濾器和打印機事件),能夠經過標準的框模型 HTML 文檔中心構造來開發大多數這些控件。其餘控件(尤爲是使用最新 CSS Grid 和 Flexbox 模型的控件)都更好地面向 HTML 元素,至少做爲容器。
此處提供了一個豐富的數據驅動圖表的示例。 儘管該示例的輸出沒有架構好,但顯示的最終結果正確。 圖形和圖表控件是衆所周知的難開發,但第三方以及 Microsoft 已經成功了。 經過在客戶端或服務器端提供最新的數據綁定抽象,客戶端的 Web 呈現主要保持靜態或者須要插件,這樣可減輕開發人員的負擔。 下面咱們利用了 SVG 的豐富性來提供加強的用戶體驗。 不管代碼如何(將傳遞給客戶端,又或許在未來更多的聲明性交互中使用),圖表都用兩個關鍵組件來呈現。 工具和數據。圖形工具或背景是基本的靜態 SVG:
<rect id="tipsh" x="20" y="100" width="194" height="34" rx="5" ry="5" /> <rect id="tip" x="20" y="100" width="190" height="30" rx="5" ry="5" /> <text id="tiptxt" x="40" y="120" font-size="12" font-family="Arial" fill="#ffffff" visibility="hidden">milliseconds</text> <polygon id="arrow" points="10,110 20,105 20,115" style="fill:#ffffff" /> <line x1="3" x2="460" y1="359" y2="359" style="stroke:#cccccc;stroke-width:1"/>
而後每一個單獨的數據點要麼傳遞到客戶端並進行操做,要麼在服務器上生成:
<text x="10" y="348" font-size="12" font-family="Arial">{Page}.svg</text> <rect x="115" y="350" width="86" height="8" style="fill:url(#inverseblue);filter:url(#Gaussian_Blur);" rx="12" ry="12"/> <rect x="115" y="333" width="86" height="17" rx="12" ry="12" onmouseover="changeColor(evt)" onmousemove="changeText(evt,'2 milliseconds')" onmouseout="changeTextNotOver(evt)" /> <text x="171" y="345" font-size="11" font-family="Arial" fill="#ffffff">6.1%</text>
http://samples.msdn.microsoft.com/workshop/samples/graphicsInHTML5/svgchart.htm
經過最新瀏覽器中提供的現有向量圖形技術的分析功能,能夠交互方式使用標準 Web 技術來知足現有的和新的方案。 從今之後,咱們將擁有巨大的機會可讓聲明性動畫支持廣告版位。 經過使用方案驅動的功能開發,咱們能夠在競爭中處於領先地位,並在 Web 應用程序和網頁中提供基於標準的圖形豐富的體驗。