杂记-day1-1

记录这半年来学到的东西，内容有错大家及时指正，不想指正可以当我瞎扯，我不对这个结论负责(KOL脸)

---

今天讲点什么好呢，秉承着先易后难的原则，今天先讲讲容易一点的。讲讲点阵吧，想到哪讲到哪

1. 显示技术发展之初，就是一个点，亮或者灭。

2. 后来有了八段数码管，就是八个点，又出现了两种接法，共阴极和共阳极。

3. 而后出现类似12864这类的液晶屏，为了节省IO资源，我们将一维的顺序，升级为seg 段和com端，这种“二维”的控制手段。

4. 而后又利用诸如[255,255,255]三个字节来表示单个点的色彩，于是我们有了控制彩色TFT的能力。

5. 后来大家发现，seg和com可以用约定的顺序规定，加之数据传输速率可以做的很高，于是就只传输RGB565 RGB888并行的16个位或24个位，而用行同步和帧同步控制数据的同步问题，从而有了控制大分辨率高色彩屏幕的能力

传统开发来说，我们不会用低性能单片机进行复杂的运算以得到漂亮的图形，但是现在越来越有本地计算的趋势了，我们还是就传统而言，我们会提前生成单个字符、图形，然后采用简单的处理，进行对称、组合之类的操作，以生成期望的显示效果，有事也会为了换取时间性能，将整张图片放入非易失性存储器（NVM）中。

举个例子，我想显示

你好，世界！

这句话，怎么处理呢。有两种方式，我直接做一张BMP图片，然后按照一定的顺序转换成C数组，而打点显示的时候，或者高级一点，放入显存的时候，也按照这个顺序，就能复现出来，这种方式速度快，空间占用大，还有一种则是，我把这个六个字符分别存进nvm，然后取一个别名，要显示的时候，一个一个找出来显示，在需要显示大量信息的时候，第二种必然是优选方案。

但是别高兴的太早，我要显示多语言怎么办呢？你肯定要说，这还不简单，都放进去找不就完事了么。、

不，事情没有这么简单，我们先从找字库这件讲起，比方说，你，这个汉字，我把他的字库图片放入NVM，取了一个别名叫“你”，保存下来，文件的编码格式直接影响你的查找结果，GB2312 和UTF8存储的数值并不相同，所以当你看到项目是中英双语，需要改成更多语言的时候，首先想到的就是，文件的编码格式是否支持。

这个世界的语言文字是丰富多彩的，汉字是表意象形字，通常占据的是方块，例如24*24，而英文是表音字母，通常是12*24，如果我们使用汉字的方式去计算hello,世界！，等待我们的将是h e l l o , 世界！，这个处理起来其实比较容易，我们可以轻松的通过编码得知，这个字母是汉字还是英文字母，从而适应他的宽度。

这个世界的语言文字是丰富多彩的，比如阿拉伯语，这种语言的语序是从右向左读，而数字确实从左至右，对此我们需要进行特殊的处理。

这个世界的语言文字是丰富多彩的，再比如阿拉伯语，这种语言有特殊的连写规则，如果字母的排列顺序满足一定的标准，那么可以对字母进行连写，这个时候我们就又需要进行连写的处理。

这个世界的语言文字是丰富多彩的，比如汉语，汉语的笔画从严格意义上来说，并不是等宽的，所以在低分辨率的场景下，特别容易出现该粗不够粗，该细特别细的情况，从而影响显示效果。对此我们又需要特殊处理。

这个世界的语言文字是丰富多彩的，再比如汉语，高分辨率场景下，我们可以通过色彩的透明度，来达到平滑的显示笔画的边缘，而在有些场景下，我们无法控制色彩的透明程度，这个时候我们要进行抗锯齿的处理。

讲了好多都是理论，有机会讲下实操。