關於瀏覽器端 Canvas Hit Region API 和結構化的圖形

原先的計劃是 Quamolit 項目在 Canvas 上模擬 DOM 來寫應用,
本身的實現會喪失大量 DOM 的好處, 並且力有不逮, 但着重改善幾個方面:

• 每一個元素有自身的生命週期, 而生命週期容易綁定動畫, 以及生成有視差和延時的漸變

• 元素經過 id 來標識, 那麼當元素從樹的一個位置移動到另外一個, 也能由框架生成漸變

目前以及嘗試過的部分看來, 效果不會太好, 代碼生成的插值, 太單調了
另外, 涉及到 transform 的圖形的控制, 帶來了新的麻煩:

• transform 以後點擊位置難以計算

• transform 是經過 Canvas 的機制完成的, 元素在樹的層級之間跳躍是難以插值

我下面先說這兩個問題:

Hit Region 來計算位置

上邊的第一個 transform 後的位置, 須要實現事件系統的話就須要能拿到正確的位置
實際上我想不出來, 幸虧回過神來去 StackOverflow 問了一下, 拿到了答案:

http://stackoverflow.com/a/28762735/883571

一個是 ctx.isPointInPath() 這個 API, 能夠原來判斷點是否落在當前渲染的 Path 中
可是這個比較難用, 並且有事件時不大可能會渲染一個判斷一次的

若是是我本身來設計 API, 我固然是但願 Canvas 每一個像素點上能直接拿到對應的標識
後來我在 W3C 的規範裏看到了, 並且答案原來也提到, 有 Hit Region 能夠用:

http://www.w3.org/TR/2dcontext/#hit-regions
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/addHitRegion

canvas.addEventListener("mousemove", function(event){
  if(event.region) {
    alert("ouch, my eye :(");
  }
});

// eyes
ctx.beginPath();
ctx.arc(70, 80, 10, 0, 2 * Math.PI, false);
ctx.arc(130, 80, 10, 0, 2 * Math.PI, false);
ctx.fill();
ctx.addHitRegion({id: "eyes"});

這個 API 容許在像素點設置 id, 設置鼠標圖片, 以及其餘一些選項
問題在於 API 只有 Chrome Firefox 實現, 而 Chrome 須要在 chrome://flags 手動開啓
做爲 Canvas Exprimental API 存在, 我在 GitHub 搜了, 也極少有項目用到

順着這個 API 的思路日後想, 當咱們給 Canvas 設計一套相似 DOM 的結構之後
經過 Region 返回的標識, 咱們就能把像素上的編輯映射到對應的元素
那麼, 幾乎可以從新實現一套 DOM, 更重要的是, 繞過了 DOM 和 CSS
好處是, 咱們的元素很是輕量級, 不受 Layout reflow 約束, 並且能任意繪圖
也能夠想見沒有 CSS Box Model 寫代碼會挺痛苦.. 不過卻是值得嘗試

Transform 之後的插值漸變

好比設計這樣一個結構, 做爲我在 Quamolit 設計的標籤樹:

RootElement
  ElementA
    ScaleH
      ElementI
  ElementB
   <PlaceC>

ElementI 在 ScaleH 當中, 最好是用 ctx.save() ctx.restore() 這套機制
在 ElementI 當中就不須要手工計算甚至複雜圖形, 就可以完成 transform 了
可是, 假如 ElementI 須要漸變到 PlaceC 呢, 中間怎樣插值?
直接的辦法是拿到 ElementI 所有的 transform, 而後計算

但是問題可能很複雜, 這裏樹的結構簡單, transform 也簡單, 可框架須要考慮複雜狀況
當 ScaleH 的位置被大量的 transform 取代, 甚至 PlaceC 也包裹在 transform 中呢?
我感到狀況將會變得很是複雜, 而我毫無信心在本身能控制的複雜度內完成...
我須要找到巧妙的辦法才行, 否則又是無法寫下去的

結構化的圖形

我在設計 Quamolit 的運行環境的時候, 不知不覺用到了虛擬機的思路
就是把 Canvas 基本操做設計成一些指令, 而後框架生成這些指令出來運行
這樣, Canvas 對我來講, 就是一個虛擬機, 我用高級的 API 去操做
或者, 類比一下 SVG 的想法, 跟 Canvas API 的寫法, 後者就是虛擬機的指令的樣子

我是追隨聲明式編程的, 甚至聲明式寫動畫. 那我天然認爲 SVG 是高級的方案
Canvas API 過程式的寫法, 不如 SVG 的寫法更適合模塊化, 也不夠直白
如今不少的 Canvas 類庫, 採用的雖然更靠近聲明式, 但依然是 API 的過程式調用
那麼我認爲, 將來相似 React Canvas 的方案深化出現, 纔是好的方案
...固然我注意到 React 在 DOM 上受到限制, 生成動畫和漸變有很多缺陷

同時, 跟着上邊虛擬機的類比, 虛擬機提供了新的語言, 能夠用更高級的思惟編程
那麼, 對於圖形而言, SVG 一類的方案是否也有着相似編程語言種種特性呢?
好比說, CSS 某些屬性在 DOM 上繼承, 就像是編程語言做用域的穿透似的
那麼是否能夠參考編程語言提供給代碼控制離的方式, 提供給圖形元素這樣的控制能力?

fibonacci = (n) ->
  if n <= 2
    fibonacci(n - 1) + fibonacci(n - 2)
  else
    1

好比 fibonacci 能從外層的閉包獲取數據, 自身進行判斷和計算
那麼, 對於圖形元素而言, 獲取父元素位置信息, 判斷和計算是不是基本的功能?
咱們原先設計的 CSS 佈局, 很大程度就屏蔽這種內部元素探測環境的機能
那麼我想, 讓每一個圖形元素都有能力自身進行計算, 就想 React, 是否是更好?

並且做用域以及數值, 就和各類圖形元素產生一些對應關係咱們是否是能夠模仿編程語言, 提供圖形編程更多的編程能力而且以之爲基礎, 完善一套聲明式編程圖形界面的更清晰的思路?到這裏, 是個人一些猜測, 固然我仍是要繼續考慮和探索一下