LCUI 0.12.5 开发日志
2012年08月08日 · 5518 字 · 阅读
2012-8-8
原来，字符串处理函数都有处理uncode字符的版本，比如：swprintf, vswprintf, wscanf, wprintf等。但是，让LCUI支持UTF-8编码的字符的处理，怎么实现？
修改了LCUI初始化时打印的文字内容。 纠正了触屏的问题，纠正了在24位和16位色彩的显示器上显示的问题。
由于还不会用git，本以为git add src/LCUI_Main.c会只更新src/LCUI_Main.c文件，于是就git commit -a -m “update Write_Graph_To_FB(), add print_screeninfo(), modefy LCUI_Init()”，用git push origin master失败，就用了git push -f origin master，结果，把所有已更新的文件上传了，还加了同样的message，这看着好蛋疼。
在设备上测试，发现图形刷新速度很慢，看来，需要加些代码，用于计时，看看是哪里耗时多。
2012-8-9
下载MiniGUI，SDL，OpenCV的源代码，留着有空看，毕竟LCUI的图形绘制需要优化。
交叉编译原来是用：/configure –host=mipsel-linux –build=i686， 记得以前用./configure –build=mipsel-linux –target=mipsel-linux 也可以啊。
在交叉编译时，发现交叉编译器给出了警告，LCUI_PictureBox.c中的某个变量未初始化就使用了它，而用gcc编译器编译却没任何警告，该问题已纠正，具体可到这里查看。
测试发现，Processing_Screen_Update()函数花费了4690000毫秒（4.69秒）的时间才完全刷新显示出图形界面，这效率，需要优化了。
区域刷新发现一个问题，各个区域刷新不同步，小区域最先刷新完，大区域刷新延迟。
写了个测试程序，用于测试不同字体的显示效果，测试过程中，纠正了字体处理的一些问题，完善了Label部件的字体位图刷新。
2012-8-11
之前LCUI都是将字符串当成GB2312编码对待，先遍历字符串，将全角字符转换成单个UTF-8字符，再转换成单个Unicode字符，非全角字符直接赋值就可以了。
iconv呢，GB2312转换至UTF-8编码倒是没问题，但UTF-8转换成Unicode就有问题了，做了很多次测试，将形如wchar_t str =L”内容123″ 这段代码作为参照对象，测试自己写的代码生成的Unicode字符串内容是否与该参照字符串一致，但结果都不满意，ASCII编码的字符倒是正常，可对于汉字，乱码了。
为了让LCUI直接支持UTF-8编码的字符串，我百度+谷歌了一下“UTF-8 转换 Unicode wchar_t”，但找到的代码，大多有问题，他们测试是用1个汉字测试，可是我测试，用多个汉字再掺杂些字母数字，得出的结果不正常，只有一个字倒是正常。
经过几个小时的折腾后，我也懒得找了，自己写算了，参考了这篇文章：http://wangblog.org/2007/12/utf-8unicode.html ，说了UTF-8编码的原理，细心看过后，原来对于ASCII编码范围以外的字符，就用多个字节表示，第一个字节中记录了这个字符总共占了多少个字节，例如： 1110xxxx 10xxxxxx 10xxxxxx ，开头第一个字节中有3个1，表示该字符用了共三个字节来储存字符编码，后面的字节，都是10开头的。
知道单个字符用了多少个字节，就可以用之前的函数将这个字符转换成unicode的字符，具体可以看LCUI_Font.c文件的源代码。
将源文件的编码由GB2312转换成了UTF-8，上传至GitHub.com，结果，GitHub在显示源文件哪里经被改动时，中文是乱码的，估计GitHub在对比两个版本的源文件时，默认以老版本源文件的编码为准，显示改动内容时，UTF-8编码的中文被当成GB2312处理，导致显示乱码。
2012-8-17
目前的刷新方法，是将记录的刷新区域，分割成若干个不重叠小矩形，方便区分出完全透明和不透明的图层，省去了不必要的图层合成。 但是，存在一个问题，小区域比大区域的刷新速度快，导致图形刷新不同步，具体可将照片查看器的窗口尺寸和PictureBox部件的尺寸改大一点，越大效果越明显。
为解决这一问题，我想出了这一方法： 处理好每个区域的图形，然后统一进行刷新；从上往下，将图形的每行像素点一行一行的刷新，当然，刷新前，需要进行记录，例如：每行需要填充多少个像素点，这一行有多少个线段，线段的起点和终点又在哪？
图形处理上，有时载入了一张图，程序用到的各个图形元素都来自这张图，按照之前的做法，需要从图中裁剪出各个图形元素，但个人认为“裁剪”这一操作可以不用做，“裁剪”的目的只是为了引用图层中某块区域的图形，供图像合成时使用，没必要再开辟空间储存裁剪出来的图形副本。 因此，图形数据需要添加“引用”功能，可引用另一个图层中某个区域的图形数据。 假设图层A是“实体”，图层B，C，D，E，F等都是“虚体”，都是引用了图层A中某个区域的图形，那么，它们之间的引用关系可以这样：A<—B<—C<—D<—E<—F<—…. ，相关处理方法可利用部件区域处理的代码，因为部件的“容器”功能和这个类似。
相关的图形处理函数的代码也需要进行修改，为了支持“引用”功能。
2012-8-19
正对 项目网站上的网页进行修改，准备让网页能够播放背景音乐，用了iframe标签，实现框架。
2012-8-20
发现了一个网站：http://adf.ly/1583326/banner/http://baidu.com，这网站的框架可以借鉴一下，iframe尺寸自动适应浏览器，也不错。
项目主页添加了背景音乐，网页源代码做了修改。
2012-8-21
完善了对“引用”图像的支持，解决之前处理所出现的问题，修改简化了alpha混合公式，具体看这里。
2012-8-22
准备做个游戏，考虑到游戏中的图形要动态的，比如：角色行走动画，需要让PictureBox部件支持动画显示，新增一个数据类型，用于保存动画信息，例如：每一帧的图形，总帧数，当前帧，每一帧的切换所需的延迟时间；
用一个线程完成这些动画的每一帧的更新，还需要一个“库”，能够记录总动画信息；再加个队列，用于记录需要进行帧切换的动画，按照延迟时间从短到长排序，每一帧更新完后，将下一帧的信息添加到队列，重新排序。
2012-8-25
添加ActiveBox部件，为了实现动画播放，想不出其它即准确又简短的名字，只有用这个了。
windows上搭建了Android开发环境，为以后向Android发展而准备。
2012-8-30
ActiveBox部件已经基本完成，效果图如下：
创建了三个ActiveBox部件，分别为它们添加不同的动画。
2012-8-31
纠正了部件在快速移动时产生的图形残留的问题，在运行label测试程序时，发现窗口在快速移动时会产生图形残留，残留的不是一部分，而是整个窗口的图形，为此，看了一下相关源代码，修改之。
复选框和单选框的测试程序运行起来卡卡的，窗口一移动，刷新缓慢，需要解决这问题。
即使缩进宽度为8，github上的显示效果和自己的编辑器显示的也不完全一样。
2012-9-2
先使用Set_PcitureBox_Size_Mode()设置为SIZE_MODE_ZOOM，然后使用Set_PictureBox_Image_From_Graph()为PcitureBox部件添加图像，结果，出现异常，调试时发现，由于部件尺寸还未进行更新，默认为0，导致计算出的缩放比列为0，以0做除数的话，会触发一些BUG，有时会使屏幕区域刷新异常。
PictureBox部件还存在问题，正在解决。
问题已解决，可查看：PictureBox部件的修改记录 和 图像处理代码的修改记录。由于一时疏忽，把那个测试进度条的源文件当成照片查看器的源文件上传了。
修改了一下进度条测试程序，效果如下图所示：
2012-9-4
学习机上测试，发现点击窗口上的关闭按钮后，程序无法退出，调试过程中，发现是由于在移除程序信息时，使用了“写”锁，而对程序进行析构时，析构函数需要调用函数获取程序信息，使用了“读”锁，因此，阻塞了。
正考虑是否放弃现在的屏幕局部刷新方法，有时分割出来的矩形过小，影响了整体刷新速度。
取消了之前的区域矩形分割，不再将区域与部件区域进行检测，只对具有重叠部分的区域进行分割。
2012-9-5
借鉴了libjpeg的configure.ac文件，修改自己的configure.ac文件，主要是对它的编译过程输出信息比较短而感兴趣。
设备上测试，尺寸为320×240的有alpha通道的图形，进行51次合成，1秒钟合成完一次，这速度太慢了，alpha通道全为0比alpha通道全为255的合成速度快，但也就快一点点，还是1秒合完一次。
2012-9-6
在用进度条测试程序测试新修改的图像合成是否有问题的时候，没事移动鼠标，鼠标指针在进度条边缘处，跟着进度条闪过的PictureBox部件移动，结果，发现鼠标指针所在的区域中，有PictureBox部件的图形，理论上PictureBox部件在进度条部件里，它的图形也只能显示进度条范围内的，超出进度条区域的图形不会显示，后来看了源代码，原来是只做了图像混合叠加操作，没有根据该图形的有效显示区域来处理图形。
用gdb测试程序时，发现段错误出在那个内联函数rgba_mix()内，按理来说，这个内联函数会被编译器展开，不会存在独立的函数；
又用了gcc编译器将LCUI_Graphics.c翻译成了汇编代码，搜索Mix_Graph，看了Mix_Graph函数的汇编代码，发现它使用了call rgba_mix，原来编译器没有把这个内联函数展开，还是还原成以前那种方式；之前在学习机端测试，320×240图形进行一次alpha图形混合都用了1秒多。
具体修改内容，请看这里。
PC端测试，对1640×1480的图像进行256次alpha混合，平均每次耗时只减少了20000ms。
学习机端测试，对320×240的图像进行51次alpha混合，平均每次耗时50000ms，效率有显著的提升。
2012-9-7
试着为LCUI添加C++接口。
添加了一个简单的类，只用了LCUI_Main()和LCUI_Init()函数。编译时，发现g++报错说这两个函数未定义，百度了一下，看了这篇文章：http://www.2cto.com/kf/201009/74570.html ，原来是因为C语言和C++语言编译出来的函数符号名不一样。而C++和编译器的设计者早已料到了这个问题，并提供了一种通用的解决办法：使用extern “C”来修饰旧C库的外部函数声明。
2012-9-8
花了一些时间折腾了C++的类，LCUI的部分C函数接口已经整理进了C++类，当使用g++编译这源代码时，会默认包含LCUI的C++头文件，通过检测是否定义 __cplusplus 宏就能知道编译器是C的还是C++的，然后确定是否该把C++版头文件包含进来。
tcc的速度的确比gcc的快。
2012-9-9
完善了区域图形刷新方法，每次结束图形的“写”操作时，LCUI会根据图形内容设定属性，方便区域刷新时利用。
修改了照片查看器，载入图片时用ActiveBox部件显示动画，如下图所示：
其它地方做了细节上的修改。
LCUI 0.12.5已经发布。
2012-9-10
学习机端测试照片查看器，发现有些问题，按键b的事件被关联两次，导致按b键后，向后切换了两张图，而不是一张。
看了照片查看器的代码，可以不用创建这么多线程，于是又做了一次修改，可到这里查看改动记录。
电脑端想测试使用更大一点的窗口，把照片查看器的尺寸调整为640×480，但发现“引用”图形的数据异常，导致图形处理出错，添加了数据有效性检测。
修改完成，测试载入2800×4000分辨率的图片，耗时也不多。
2012-9-11
决定将之前修改的audio.js的示例html代码添加至项目主页，实现网页音乐播放器。想实现QQ音乐主页上那种折叠式播放器，一开始播放器是隐藏的，只有个按钮在边上，点击按钮后，播放器就会显示出来；百度搜索了一下，关于“div 接受鼠标点击事件”的，测试了找到的示例代码，效果正常。
又百度搜索“js 控制div位置”，找到的一些结果貌似不怎么沾边，用 obj = document.getElementById(“对象ID”); 可获得对象，然后就是obj.style.xxxx 修改xxx属性，中途走了些弯路，在此不作过多说明。
通过鼠标点击来展开/折叠播放器的功能已经实现，可是，没有QQ音乐主页那个播放器的那种动画效果，用谷歌浏览器审查元素，发现在显示动画效果的过程中会显示如下图所示的内容：
对这个transition表示好奇，于是百度谷歌之，看了这篇文章：http://www.qianduan.net/css-transitions-101.html
感觉效果不错，原来QQ音乐主页的播放器的动画效果是用这个实现的啊，好吧，添加两个class，right属性分别用不同的值，按钮响应鼠标事件时，就直接切换播放器的div的class即可，而transition属性则通过id绑定，因为它是固定的，不需要变动。
具体效果请查看 LCUI 的项目主页。
文章版权归作者所有，未经许可不得转载。