0x00 前言

本文适用的场景为普通的LCD或者是LED在不显示图像等特别的操作下，节省显存与相关显示的资源，是一种几乎最简单的GUI处理架构。
其实严格上讲，不算是算法，只不过算是给下面的工作做一定的前置。

阅读本文，您可能需要掌握的知识：

技能	熟练度
GUI	了解
C语言	了解

0x10 显示空间

首先，一个普通的LCD，在没有内部的专用驱动IC的情况下，都会很浪费空间（主要是内存与当前的）。例如一个完整的12864显示器，需要至少使用8192byte的内存，这对于一般的单片机来算是很大的开销了。
如果一个多彩的LCD屏幕，甚至需要更大的显存，还是以12864为例，全彩的显示屏需要将近24kbyte的数据显存。这个几乎一般的芯片都很难接受了。

0x20 优化空间

这里，笔者觉得，似乎可以尝试优化以下，使用简单的一种算法，将当前的显示空间简单压缩，随后使用较小的显示空间定义较大的显示空间。现有的想法经过计算，似乎128*64分辨率的显示器，显示似乎最小只需要32byte最小的运行内存，辅以4kb以内的固定数据（可以理解为字库），就可以显示足够多的Ascii字符（暂时只是这样简单计算，后期也许会支持更大的显示空间计算与计算方案）。

0x30 计算原理

0x31 空间计算

一个完整的空间，一般可以抽象为一个简单的三维数组。这里笔者因为只是最简单的建模，所以就可以抽象一个最简单的三维数组（128*64*1）的基础数组。

0x32 文字编码

一个最简单的文字可见编码主要为16*16，基本上已经可以显示绝大多数的数字与绝大多数的文字了。

0x33 计算结构

上述的几个参数，就可以知道，在最密排列下，当前的整个屏幕显示的结构，约为 32byte,当然，这个只是最简单的显示Ascii字符，如果是Unicode-16这种就需要64byte。
也就是一个12864的显示屏，在具体的16bit*16bit的显示条件下，就是需要占用(128/16 -((128%16)>1)) *(64/16- ((64%16)>1))的实际数据。

0x40 实际实现方式

首先，笔者假设现在有一个12864的屏幕，现在笔者将其划分8*4的Ascii结构（简单数组）于是就可以通过简单的查表进行显示。
还有部分的显示区块，也就是常说的字库。这部分一般是存放在外部的存储空间内，因为不需要经常更换，甚至可以存放在非易失性的结构内。

graph LR
A[获取偏移值] --> |偏移寻址| B(渲染到屏幕)

这个操作下保证RAM下只存储偏移值，也就保证了当前的结构最简、使用内存最小。

0x50 总结

简单来说，暂时的实现方式还只是使用字库映射的方式，对于当前的显示区块进行显示的操作来节省当前显存的结果。
这种显示方法广泛应用在较高算力的众多的机器中，但是在嵌入式低端还较少。主要因为当前的嵌入式计算能力高度定制化，随着嵌入式的芯片计算能力、冗余能力越来越大，当前的显示有了这种显示方式的可行性。