分類: 技術

WebGL 小註解

WebGL 正如其名, 具有 Web + GL 兩種性質. 它是一個 3D rendering 的 API, 修改自 OpenGL ES 2.0, 而且它使用 Web browser 當作 middleware. 只要有 browser, 就可以用 HTML 來畫 3D.

當然, 此時 WebGL 需要借助 HTML 的 CANVAS. 下面是 CANVAS 的一個例子, 說明 canvas {} 可以畫出圖來. 只不過這個例子是 2D 的, 而不是 3D 的.

大家可以發現, canvas 需要先做一個類似宣告的動作. 以便取得 ID (假設是 xxx 或是上面例子中的 tutorial.

var canvas = document.getElementById(‘xxx’);

然後再用這個 ID 取得 context, 有了 context  就有 drawing buffer. 和其他語言一樣, 第二次用同樣的名字去 getContext, 只會傳回同樣的內容, 不會再 create 新的  object . 

var ctx = canvas.getContext(’yyy’);

至於 drawing buffer 的內容, 主要是 color (8 bit), depth (16 bit), 和 stencil (模板 8 bit).

那麼 view point 呢? 表示方法如下, 由四點所組成的矩形構成四個參數:

ctx.viewport(0, 0, canvas.width, canvas.height);

 在陰影處理的部分, WebGL 支援 GLSL (OpenGL ES Shading Language). 

最後要提一下 DOM (document object model), WebGL 也會用到它. 因為 DOM 是跨 HTML, XHTML, XML 的資料表示方法. 所以 WebGL 的 function 和 interface 是用 DOM 來描述的.

對了! 據說所有知名的 browser 都打算支援 WebGL, 除了 IE9 不想放棄自家的 DirectX 之外.

[ref] WebGL Specification V1.0

 

MCS 小註解

關於無線網路的速度問題, 有一個標準的指標 – MCS (Modulation and Coding Scheme). 只要用 MCS 就可以概略知道傳輸速度, 而不需要講出實際的數字.

下表取材自 WIKI, MCS index 就是指速度的指標. 比方說我支持到 MCS7, 他支援到 MCS15 之類的. Spatial Stream 是指空間流或是空間串流, 要明白空間串流就要先明白空間分集. 假如在訊號的發送端有多個天線, 而每個天線的訊號都會透過不同的路徑到達接收端的天線, 這樣就構成了空間的分割或是分集. 如果天線不夠多支, 也就無法做到分集. 11n 的規範最多就是支援 4 支天線.

Modulation type 就是通訊原理裡面講的調變方法. Coding rate N/M 是指傳送 M bit 時, 裡面有 N bit 是 data, 當然 M – N 就是 redundant 了. Redundant 不是沒有用, 反而可以防錯或是校正錯誤.

20 或 40 MHz 是通道的頻寬, 這個一看就知. 不過這個 GI 呢？如果傻傻去 Google GI 不會有什麼好下場. 由於 GI 的單位是時間, 所以可以猜到 I 表示 Interval. 對, GI 就是 Guard Interval. 在兩個 OFDM 的 symbol 之間的傳送間隔即為 GI. GI 愈短, 則傳輸速率愈高.

在 4 根天線的狀況下, 距離不要太遠 (coding rate 高) 的話, 11n 可以達到 600 Mbps. 而一開始講到的 MCS7 和 MCS15, 其他的條件都是一樣的, 只差在空間串流的數目. 這點可以從天線的多寡很快判斷出來, 沒有兩根天線是不可能做 MCS15 的.

MCS
index		 Spatial
streams		 Modulation
type		 Coding
rate		 Data rate (Mbit/s)
20 MHz channel 40 MHz channel
GI = 800 ns  400 ns  GI = 800 ns 400 ns
0 1 BPSK 1/2 6.50 7.20 13.50 15.00
1 1 QPSK 1/2 13.00 14.40 27.00 30.00
2 1 QPSK 3/4 19.50 21.70 40.50 45.00
3 1 16-QAM 1/2 26.00 28.90 54.00 60.00
4 1 16-QAM 3/4 39.00 43.30 81.00 90.00
5 1 64-QAM 2/3 52.00 57.80 108.00 120.00
6 1 64-QAM 3/4 58.50 65.00 121.50 135.00
7 1 64-QAM 5/6 65.00 72.20 135.00 150.00
8 2 BPSK 1/2 13.00 14.40 27.00 30.00
9 2 QPSK 1/2 26.00 28.90 54.00 60.00
10 2 QPSK 3/4 39.00 43.30 81.00 90.00
11 2 16-QAM 1/2 52.00 57.80 108.00 120.00
12 2 16-QAM 3/4 78.00 86.70 162.00 180.00
13 2 64-QAM 2/3 104.00 115.60 216.00 240.00
14 2 64-QAM 3/4 117.00 130.00 243.00 270.00
15 2 64-QAM 5/6 130.00 144.40 270.00 300.00
16 3 BPSK 1/2 19.50 21.70 40.50 45.00
17 3 QPSK 1/2 39.00 43.30 81.00 90.00
18 3 QPSK 3/4 58.50 65.00 121.50 135.00
19 3 16-QAM 1/2 78.00 86.70 162.00 180.00
20 3 16-QAM 3/4 117.00 130.70 243.00 270.00
21 3 64-QAM 2/3 156.00 173.30 324.00 360.00
22 3 64-QAM 3/4 175.50 195.00 364.50 405.00
23 3 64-QAM 5/6 195.00 216.70 405.00 450.00
24 4 BPSK 1/2 26.00 28.80 54.00 60.00
25 4 QPSK 1/2 52.00 57.60 108.00 120.00
26 4 QPSK 3/4 78.00 86.80 162.00 180.00
27 4 16-QAM 1/2 104.00 115.60 216.00 240.00
28 4 16-QAM 3/4 156.00 173.20 324.00 360.00
29 4 64-QAM 2/3 208.00 231.20 432.00 480.00
30 4 64-QAM 3/4 234.00 260.00 486.00 540.00
31 4 64-QAM 5/6 260.00 288.80 540.00 600.00

DHCP 之 APIPA

最近客戶又要 daily review 了, 趁著開會前, 老婆還在煮晚餐的空檔, 整理一下客戶發的 bug.

APIPA 全名為 Automatic Private IP Addressing, 也就是自動獲取 IP address 的規範. 當我們使用 DHCP (dynamic Host Configuration Protocol) client 的時候, 機器會先發出 discover 的封包, 找尋 DHCP server.

此時, 機器不知道自己該拿哪個 IP, 所以會先用 0.0.0.0 去廣播. 如果找得到 DHCP server, DHCP server 就會分配一個沒人用的 IP 給剛才的機器.

由於 IP address 有限, 在人來人往的麥當勞, 發給客戶的 IP 都是動態的, 如果租約到期, 這個 IP address 就會被回收. 如果是 automatic allocation, 那麼分到 IP address, 都可以一直用下去. 例如公司有線網路的 DHCP 就適合這麼做.

但是找不到 DHCP server 又怎麼樣呢? Windows 2000 以前的做法是保留 0.0.0.0, Windows 2000 以後的做法就會隨意用 169.254.xxx.yyy 的位置, 搭配 255.255.0.0 的 submask 來充當例外時的 IP 設定. 這樣就算沒有 DHCP server, 仍然可以達到自動獲取 IP 的目的.

Quadrant Benchmark 小註解

 Quadrant  是 Aurora 公司推出的軟體, 功能是測量 Android 系統的效能. 相較於 Windows 有官方的性能評分工具, 但是分數的間距很小; Quadrant 比較像是 3D Mark 那樣, 能夠給出比較拉得開的分數. 除了總分, 也可以對 CPU, Memory, IO, 2D 和 3D 做出評價 (Advanced 以上的版本).

假如不用 Quadrant, 有沒有其它的代替方案呢? 有, 前三名還包括 Linpack 和 Neocore. 據說 CF-Bench 也可以測多核心 Android 系統的效能, 差別在於它不測 GPU.

只要用 Google 圖片去 search quadrant, 就可以看到很多 “第一名" 自拍. 我看到最厲害的是 3278 分. 客官啊, 這個 bench mark 的 bench mark 是 1 千多分, 破 3000 分是怎麼來的呢? 原來是有人破解了 Qudrant 的計分標準. 它的罩門在於 IO 速度這一項.

這位 Cyanogen 老兄發現, 只要把 Qadrant 測試用的目錄, 設在用 memory 模擬的 file system 下面, 就可以靠著 IO 方面的優勢, 獲得不可思議的高分. 引用 WIKI 的說明, 下面原文中提到的 tmpfs, 就是用 mount -t tmpfs -o size=1G, nr_inodes=10k, mode=0700 tmpfs /space 之類的指令, 把 1GB 的記憶體, 指定給 space 這個目錄夾使用. Quadrant 拿這個資料夾去測 IO, 當然就不察而給予過度高估的評價.

In Cyanogen’s tweet, he says he was able to exploit the flaw to get obscenely high Quadrant benchmark scores by mounting “a tmpfs over quadrant’s data directory.” A tmpfs, or temporary file storage system, can artificially inflate a device’s I/O score and provide unreal benchmark improvements.

這篇文章的原作者提到, 既然 Qadrant 有 bug, 所以參考意義不大. 不過我想到如果各家廠商要 PK Qadrant 的時候, 說不定也可以用這個技巧來欺騙對手…哈!

[ref] http://briefmobile.com/cyanogen-demonstrates-quadrants-flaws

Pattern Insight 的妙用

Pattern Insight 是一個商業軟體, 用來保障 （不是保證）release 出去的 code, 不會有先前已經 fix 過的 bug.

它的原理也相當簡單, 拿一個基準點的 reversion (or commit) A, 對照一個 fix 過某個 bug 的 reversion B, 產生一個 patch 的 pattern. 然後在各個版本之間, 用這個 pattern 去 match 可能還沒有fix 此 bug 的 version (or branch), 將它high light 出來.

當然, 做為一個收錢的軟體, 諸如檔案改過名字之類的狀況, 也會考慮到. 這個軟體的精神大概就是這樣.

[試用版下載] 要填一些資料.

[Demo 影片]

Pattern Insight Clone Detection from Pattern Insight on Vimeo.