Day2 - Canvas基础概论 I - 成为Canvas Ninja ～ 理解2D渲染的精髓

Let's Start From Scratch

本系列文章的头几篇我决定还是带点基础的东西，但是我又不想讲一些太过common sense 的东西，所以这边我会介绍一些不常被一般教学提到的资料来当热身。

The HTMLCanvasElement interface provides properties and methods for manipulating the layout and presentation of <canvas> elements. The HTMLCanvasElement interface also inherits the properties and methods of the HTMLElement interface. --- from MDN
The HTML <canvas> element is used to draw graphics on a web page. --- from www.w3schools.com

上述是在MDN还有W3school上关於canvas 元素 的解释。简单来说canvas就是一种自带复数api, 然後可以用来在网页上做动态绘图的元素。
简单的介绍就到这边，接下来是疑问时间。
有些人看到上述的解释，可能会觉得很疑惑，例如：

那麽我们平常在用的CSS和html基础元素，那样子的东西难道不也是一种绘图吗? 差别在哪里?

接下来我们将针对这个问题做一系列的说明。

Canvas 与 一般 Dom元素的差异一：编译流程

通常在80%以上的web专案内容中，我们都是使用普通的Dom元素来对页面进行版面规划。
所谓『普通』的Dom元素指的就是 div、span、ul、li...,etc. 而我们都知道，HTML本身是一种标记语言，
一篇完整的标记语言范本其实就有点像某种愿望清单，为什麽说是愿望清单呢? 那是因为浏览器在接收到一份HTML时，他做的事其实就是根据这份文件，上面提到的: 这份文件有多少元素? 元素个别是哪些？ 元素的先後排列顺序、元素的巢状化逻辑...etc. 去生成各个元素的物件实例，然後再透过浏览器的渲染引擎去把这些元素渲染在画面上。

像这样子先确认页面需求模型(也就是我们提到的愿望清单)，然後将模型中的细节一一转译实现的这种行为模式，我们把它称为Retained Mode(保留模式)。
接着一定就会有人问：

那麽是不是还有别的模式呢？

Of course.
当浏览器需要做这类把文字逻辑转化成视觉的工作时(我们把这种行为称为转译)，会有两种固定模式，其一是Retained Mode(保留模式), 然後再来就是与Canvas密切相关的Immediate Mode(立即模式)。

从上面这张图片我们可以发现，Canvas 元素和Dom元素最大的区别就是创建模型的这一个环节。
所谓的模型指的其实就是彼此之间具有关联的物件(Object)的群集。
一个使用Canvas 画一个蓝色方块，和一个使用div搭配css样式做出的红色方块，本质上最大的区别除了颜色之外，就是这个方块背後物件的内容差。

举个简单的例子，我们在做网页动画的时候，常常会需要用到getBoundingClientRect 这个api 来获取一个区块的大小、座标等。
而我们在使用这个api的时候，一般就是先去抓取(query)这个元素，然後就可以用这个元素实例底下的api。

  // ele 本身是透过selector 字串所抓到的元素实例(instance), 这个实例其实是在浏览器创建Dom模型的时候new出来的
 let ele = document.querySelecor('div'); 
 // getBoundingClientRect 则是ele 这个实例物件的一个方法
 let divWidth = ele.getBoundingClientRect().width; 

上述对大部分人来说应该都是一个稀松平常的操作。
但是当我们用Canvas 绘制一个方块时，我们所创建的实例并不是透过去new 浏览器内建的Element 类(class)所建立出来的，而是透过我们自己定义的一个具有客制化方法的类，例如:

 class block{
   constructor(ctx){
     this.ctx = ctx;
   }
   draw(x, y, width, height){
     this.ctx.fillRect(x, y, width, height);
   }
 }

当我们用这样的一个客制类Block去产生一个方块的实例时，这个实例底下所有的方法，都是来自於这个客制类Block的定义（所以当然也就没有getBoundingClientRect这麽方便的api可以用）。
但是相对的，因为产生实例的类可以自己定义，自由度也当然就跟着大幅提高，平常一些不能用基础Dom元素做到的操作，甚至都变得有可能了（ex：绘制不规则图形、创作复杂动画）

Canvas 与 一般 Dom元素的差异二：使用情境

前面我们有提到, Canvas 相较於 基础Dom元素而言，具有相对高（不只高! 而是非常高！）的自由度。
用一个简单的例子来描述，就好比订制手工赛车和国产普通轿车 的区别，这边绝对不是要说国产货不好，毕竟我也没有说订制的手工赛车的来源是哪一家厂商XD

讲到这边应该就可以理解到两种绘图方式的使用情境其分野：

1. Dom元素适合的情境

• 快速/大量生产的需求
• 不想花费过多时间处理效能问题
• 有大量的互动操作行为, 例如UI/UX

2. Canvas渲染适合的情境

• 当有天马行空的创意
• 较少的时间压力，且能够自行处理图形重绘/ 效能问题
• 像素操作（这个後面的章节会提到）

就像我们前面提到的，以现阶段来讲，前端工程师80%的职业生涯中面对到的多半是第一种情境(当然也有少数人不是)，
而我们需要为了这20%的状况去学习的原因，除了要应对未来的不时之需以外，当然就是有挑战自我创作的意义存在。

那麽话就说到这边。
在接下来的章节，我们将会进入下一阶段基础的讲解，然後再逐渐的解释Canvas绘图的实作，还请各位拭目以待～。