无评论，祝好～
[ view entry ] ( 905 views ) | permalink |
( 3.3 / 299 )接上篇，曲线的构造依赖于“方程”和“空间变换”，同样图形的构造也唯一依赖于“向量”和“空间”，“向量”指代了图形本身的形状，“空间”指容纳“向量”的坐标系，上一篇我们可以通过曲线方程和空间变换函数来构造简单的平面曲线，依照这个思路我们来继续构造一个立体空间。这里不得不提到3D数学的两个基本概念，矩阵和线性变换。
矩阵是描述空间点的参数对，线性变换是真实向量投射到视觉空间的过程。通过一个点和坐标，脑海中会自然形成点的空间位置，要把这个点转换为可视的尺寸投影到2D的画布上，这就需要一个变换的过程。用线性代数的术语讲，线性变换并没有改变物体的形状，改变的只是长度、角度和体积，线性变换是“拉伸”坐标系。
向量在几何上能被解释成一系列与轴平行的位移，一般来说，任意向量v都能写成“扩展”形式：
;)
另一种略有差别的形式为：
;)
右边的单位向量就是x，y，z轴，这里只是将概念数学化，向量的每个坐标都表明了平行于相应坐标轴的有向位移。
让我们将上面的向量和重写一遍，这次分别将p、q、r定义为指向+x，+y和+z方向的单位向量，如下所示：
v = xp + yq + zr
现在，向量v就被表示成向量p，q，r的线性变换了，向量p，q，r称作基向量。举个简单的例子，[[3,2],[-2,3]]的线性变换就表示成这样
;)
坐标从x轴y轴变换到蓝色箭头，一个点，在原始坐标系中的表示和转换后坐标系的表示就不一样了，我们就依此来构造真实3D中的点到“变换后”的空间点的视觉呈现。
在js中实现了一些基础函数：清除画布，画线，缩放，画正方体。现在拿正方体作为例子，一个起始于坐标系原点，xyz轴各自伸展一个单位长度的正方体的坐标为：
[这很容易理解，如果不做任何变换，按照原始x（水平右向）轴、y（垂直向上）轴、z（垂直屏幕向外）轴进行投影，看到的只是一个长宽各为1（像素）的一个点，放大后也是一个正方形，如果要看到立体效果则需要线性变换，线性变换函数很简单：
[0,1,0],
[1,1,0],
[1,1,1],
[0,1,1],
[0,0,0],
[1,0,0],
[1,0,1],
[0,0,1]
]
//向量a做M变换，并做b偏移量这时，只要将原始立方体放大一些，做一下变换，就可以看到变换后的“立体”了。这里的demo中构造了四种形式的线性变换：无变换（初始位置），角度变换，正交变换，拉伸变换。
var matrix = function(a,M,b){
if(!b)b = [100,100,100];
var x = a[0]*M[0][0] + a[1]*M[1][0] + a[2]*M[2][0]+b[0];
var y = a[0]*M[0][1] + a[1]*M[1][1] + a[2]*M[2][1]+b[1];
var z = a[0]*M[0][2] + a[1]*M[1][2] + a[2]*M[2][2]+b[2];
return [x,y,z];
};
;)
静态立方体
Demo here（用非ie浏览器打开）
动态立方体
Demo here（用非ie浏览器打开）
其实说到这里，3D引擎的数学基础已经介绍差不多了，不论是建模还是动画，都是由“线性变换”驱动的“向量”组成的图形，因此，这种线性变换关系固定后，后续的3D开发几乎可以将着眼点放在“变换矩阵”和“向量”的构造上，而线、面和体的构造是依赖于方程，和2D相比，3D的线面体只不过将2维升级为3维，本质上和2D并无不同。
更多3D数学基础可以参照：3D数学基础。
以上～
[ view entry ] ( 1039 views ) | permalink |
( 3 / 253 )html5的canvas为前端图形编程创建了很大便利，目前已经有很多精巧的js库都在研究基于canvas的图形程序的开发。今天有时间来做一些基本图形编程的铺垫。
基本的api可以参照mozilla提供的文档canvas文档。
html5的canvas提供了多样的api来支持绘图，但这些api只限于静态绘图，或者给定参数进行一次绘图，其中矩形、原型、曲线三种绘图几乎可以绘制所有的图形，但过程相当麻烦，工程师需要预先定义好需要绘制的位置、材料、颜色等参数才行。其实，曲线方程能解决很多不必要的手工绘制工作。但原生的canvas并不提供曲线方程相关api。今天来实现一个曲线方程的绘图api。
按照惯例，依然首先构思api的接口，即首先思考如何更方便的使用api，再去实现接口。这里，作为例子，使用如下参数作为基本的曲线结构，只要这些参数给定，曲线也就无歧义的绘制出来：
1，foo，曲线方程，默认为直角坐标系方程：
2，a，x坐标闭区间，很明显，它应属于曲线因变量的坐标系，
3，boo，是否清除之前的曲线？
4，speed，绘制曲线速度，
5，step，两点之间的间隔步长，默认为1，
6，C:画布,
7，color:曲线颜色,
8，matrix:空间变换函数
9，callback：绘制结束后的回调
参数已经足够了，需要解释的是foo（曲线方程）和matrix（空间变换函数），我们知道初等数学中规定的方程有三种，直角坐标系方程（通过x，y坐标定位），极坐标系方程（通过环绕角度和长度定位）和参数方程（通过参数定位直角坐标和极坐标）。直角坐标系方程常用来绘制横向曲线，极坐标常用来绘制环绕曲线，参数方程用来绘制更复杂的曲线。而三者之间有着一对一的变换关系，都可以等价的变换为直角坐标系方程，并依此绘制曲线。除此之外，更加复杂的线性空间也是必须要考虑到的，因为在线性代数中，任意维度的矩阵所构造出的向量空间更加繁杂，也由此派生出真正的2D和3D的向量空间，尤其是正交3D变量投影到2D空间中，则需要一种特殊定制的matrix（空间变换函数），这个东西以后在说，先看简单的2D中的空间变换。
api：curve(foo,a,boo,speed,step,C,color,matrix,callback)。
其中foo若是直角系方程，matrix可以留空，比如绘制正弦和余弦方程：
y=50 sin((x+20)/10)+100;
y=50 cos((x+20)/15)+150;
sin.html(用firefox打开)
若foo是极坐标方程，则须指定matrix，例如椭圆方程：
P = e*p/(1-e*cos(a-150)) + 150
round.html(用firefox打开)
如果是参数方程，则需要指定matrix即可，在matrix中指定x和y的方程，例如参数方程：
x = a* cos(t)+10* cos((10/6-1)*t)+100
y = a* sin(t)-6* sin((10/6-1)*t)+100
;)
circle.html(用firefox打开)
或者绘制星形的参数方程
x = Math.pow(a*cos(t),3) + 100
y = Math.pow(a*sin(t),3) + 150
star.html(用firefox打开)
;)
to be continue...
[ view entry ] ( 1042 views ) | permalink |
( 3.1 / 264 )我们使用svn大概已经很熟练了，“svn up”、“svn ci”、“svn diff”和“svn st”变的几乎和ls和cd一样常用了。在做项目启动和结束的时候才会用到“svn copy”（打分支）和“svn merge”（合并分支到主干）。由于前端开发流程是依赖于后端，因此，前端资源文件“css”、“js”、“img”和“swf”等等文件也要走完这些流程，和后端代码不同的是，后端代码上线后可以直接覆盖原代码，前端代码则不总是覆盖源文件，之前讨论过这个情况。因此，前端文件则需要比较修改后，才决定哪些文件需要更新，哪些文件不需要更新。
比如，这个项目中，主干上有4个文件，和主干相比，分支项目修改了c.js和d.js，且新增了e.js
;)
由于需要代码管理，将分支也合并到主干里，但压缩上线则不可能将这5个文件重新上线，我们只需要上线修改过的c.js，d.js和e.js。svn中没有命令直接查找分支中修改过的文件，写了一个shell脚本，用来判断当前分支修改过（新增）的文件。这里需要提及的，资源文件数量只会增加，不会被删除，即只有上线，没有下线，而且，合并主干时候默认不会产生冲突，因为js和css脚本会拆分到个人，一个人负责的功能放在一个js或css文件中，因此，不会出现多人改一个js文件的可能性，这方面的控制是依赖于框架和项目管理。
脚本的使用很简单，只要保证待检查的branche代码已经完全提交且保持最新，执行脚本输出绿色为本期修改过的文件，红色为新增的文件，如果代码有新增的文件但未提交，也会显示红色，这样哪些文件需要上线就能一目了然了。
#!/bin/bash运行情况也很简单，这里修改了两个文件，新增了一个文件，但未提交，脚本执行结果是：
#检查当前目录和base相比修改了那些文件
myPath=$PWD
#准备工作
svn info | awk 'END{print NR}' > __NR
NR=`cat __NR`
rm __NR
if [ $NR -eq 0 ];then
exit;
fi
svn log --stop-on-copy > __j__svnlog
#准备比较操作
copy=`cat __j__svnlog | awk '/^r.*/{print $0}'| awk 'NR==1{print $1}'| sed 's/r//g'`
base=`cat __j__svnlog | awk '/^r.*/{print $0}'| awk 'END{print $1}'| sed 's/r//g'`
rm __j__svnlog
#开始比较
svn diff -r $base | awk '/\+\+\+/{print $2}' > __j__mfilelist #得到修改过的文件
svn st | awk '{print $2}'| grep -v '__mfilelist' | grep -v '__afilelist' > __j__afilelist #得到新增的文件
cat __j__mfilelist __j__afilelist > __j__grep_v #准备统一输出
echo "ls -lhrt | sed 's/^.*\s//g' " > __j__handledlist
sed -i 's/^/\| grep -v /g' __j__grep_v
cat __j__grep_v | tr "\n" " " >> __j__handledlist
cat __j__handledlist | tr "\n" " " >__j__handledlist
echo "#!/bin/bash" > __j__sh.sh
cat __j__handledlist >> __j__sh.sh
sh __j__sh.sh | grep -v __j__> __j__first_result
LS=`wc -l __j__first_result | awk '{print $1}'`
cat __j__first_result | eval "awk 'NR<$LS{print \$0}'" | awk 'NR>1{print $0}'
rm __j__handledlist __j__grep_v __j__first_result
#输出结果
while read line
do
echo -e "\033[32m$line\033[0m"
done < __j__mfilelist
while read line
do
echo -e "\033[31m$line\033[0m"
done < __j__afilelist
rm __j__mfilelist __j__afilelist __j__sh.sh
;)
bash脚本的运行比较傻瓜，并未做很多必要的验证，有时间会加上一些验证，增强一下健壮性。
[ view entry ] ( 521 views ) | permalink |
( 3 / 219 )原文：Graded Browser Support Update: Q1 2010
YUI team刚刚宣布2010年一季度的A级浏览器的支持报告（GBS），有了一些重要更新。这些更新包括：
1，在XP中开始支持chrome 4.0.x
2，将Windows Vista替换为Windows 7（同时将IE7降级为在xp中支持）
3，将Opera 10.x从A级降为X级。
4，将firefox3.5.x替换为firefox3.6.x
;)
这个更新报告是沿着09年第四季度制定的路线图作出的相应调整，在这个过程中有过一些重要的关于A级浏览器的讨论：
1，Chrome：Chrome咄咄逼人的增长态势促使其加入A级浏览器的行列，在GBS委员会中，大家争论的焦点在于，是否将Chrome列入测试列表中，不过如今专家已经就此达成一致。
2，Opera：根据09年第四季度的更新报告，YUI team曾着重讨论是否将Opera将为X级。他们认为YUI和YAHOO网站已经不值得再去广泛支持Opera，除非X级浏览器也被大量的使用。GBS也为进一步整理浏览器测试列表制定了路线图，并由此决定自2010年一季起将Opera和其他高质量但低占有率的浏览器一同将为X级。Opera是一款相当优秀的浏览器，我们希望Opera用户也能在yahoo或者YUI驱动的网站上有上佳的用户体验，同时我们会继续跟进网站在Opera下的bug。
3，Windows Vista和windows7：统计结果表明，多数人根本不在意有多少个版本的windows，他们只认识一个IE。实际工作经验告诉我们，在vista中的测试结果和在xp中的测试结果相差无几，并无特别重大的区别。基于此，我们将windows vista替换为更新版本的windows 7，由此保证我们将首要精力放在四个独立的操作系统上，这里包括绿色版的windows和更新的windows 7，然而vista依然有着相当大的市场占有率，因此，QA团队会继续关注Vista下的bug，一旦发现立即修改。同时我们呼吁QA团队开始将window 7列为自己的测试目标平台。
本季度的特别提醒：
GBS是一种QA哲学，而不是一个单纯的浏览器质量和占有率的报告，他是用来指导QA团队如使高效利用有限的资源，同时指导前端工程师理智的测试浏览器兼容性。我们的是保守、审慎的：我们将利用有限的资源测试尽可能少的浏览器/操作系统的组合、浏览器内核，同时达到尽可能高的用户浏览器覆盖率。
[ view entry ] ( 514 views ) | permalink |
( 3 / 190 )
