LCUI 0.12.5 开发日志

发表于2012年08月08日

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 的项目主页。