100分:开帖讨论WINCE下24位色显示瓶颈

zhuEvan 2010-10-26 09:29:39
加精
最近在搞24BPP显示,搞不定,主要是切换图片会慢
有搞过的朋友,指点指点




24BPP图片显示慢的原因:读写内存的速度限制
16BPP 30-40ms之间
另外,输出24BPP图片好像有经过二次转化,16BPP就转化一次
即16BPP输出图片,只要一次写LCD Buffer
24BPP好像是将3字节排列的源文件图片,转化为4字节格式的保存在中转地址,然后从中转地址转化成最终显示图片,写入LCD buffer,而第二次的LCD buffer地址可能为unchche的,将其cache一下,和16BPP的显示速度就相当了


例如:
Volatile int x,y;
for(y=0;y<272;y++)
{
for(x=0;x<480;x++);
}

实测用时:14.3ms!!!其中,变量是放在堆栈中,对变量的处理时间:(STR*3+LDR*4)*272*480=14.30ms-1.94ms=12.36ms

反汇编如下:
.text:10001134 SUB SP, SP, #8
.text:10001138 MOV R2, #0
.text:1000113C STR R2, [SP,#8+var_4] //y值存堆栈[SP,#8+var_4]
.text:10001140 B loc_10001170
.text:10001140
========================循环开始========================
.text:10001144 ; ---------------------------------------------------------------------------
.text:10001144
.text:10001144 loc_10001144 ; CODE XREF: LCD_TST+44j
.text:10001144 STR R2, [SP,#8+var_8] //x值存堆栈[SP,#8+var_8]
.text:10001148 B loc_10001158
.text:10001148
.text:1000114C ; ---------------------------------------------------------------------------
.text:1000114C
.text:1000114C loc_1000114C ; CODE XREF: LCD_TST+2Cj
.text:1000114C LDR R3, [SP,#8+var_8] //从堆栈取出x
.text:10001150 ADD R3, R3, #1 //x++
.text:10001154 STR R3, [SP,#8+var_8] //x值存入堆栈
.text:10001154
.text:10001158
.text:10001158 loc_10001158 ; CODE XREF: LCD_TST+14j
.text:10001158 LDR R3, [SP,#8+var_8] //堆栈取出x
.text:1000115C CMP R3, #0x1E0 //x<480?
.text:10001160 BLT loc_1000114C //x<480则跳到114C处
.text:10001160
.text:10001164 LDR R3, [SP,#8+var_4] //取出y
.text:10001168 ADD R3, R3, #1 //y++
.text:1000116C STR R3, [SP,#8+var_4] //y存入堆栈
.text:1000116C
.text:10001170
.text:10001170 loc_10001170 ; CODE XREF: LCD_TST+Cj
.text:10001170 LDR R3, [SP,#8+var_4] //从堆栈取出y
.text:10001174 CMP R3, #0x110 //y<272?
.text:10001178 BLT loc_10001144 //y<272,则跳到1144处
.text:10001178
====================循环结束============================
.text:1000117C ADD SP, SP, #8
.text:10001180 BX LR


...全文
1691 94 打赏 收藏 转发到动态 举报
写回复
用AI写文章
94 条回复
切换为时间正序
请发表友善的回复…
发表回复
简单并快乐着 2012-11-12
  • 打赏
  • 举报
回复
关于wince RGB888 24 bit 为什么没什么人搞? 因为wince很多屏幕并不大的,大部分屏幕都是RGB565 的16 bit ,所以BSP都是默认的RGB565 16 bit RGB888 24 bit 是可以搞的,ARM的 CPU也支持24 bit 但是为什么32 bit 没人搞? 因为ARM 没有出支持32bit 的LCD控制器。 所以没必要啊,估计以后ARM强大了会有。 现在很多手机都是RGB888 24 bit ,效果也相当的好了。 至于如果是VGA的,这种情况,用RGB888 24 bit 已经足够了。
简单并快乐着 2012-11-12
  • 打赏
  • 举报
回复
case 32:
  *(unsigned long *)dst.Ptr = (unsigned long)src.Value;
把24 bit 的当做32 bit 就可以一次传输过去。嘿嘿,好办法!
简单并快乐着 2012-11-12
  • 打赏
  • 举报
回复
引用 39 楼 JNU_kinke 的回复:
你要在驱动中和初始化LCD为32bit颜色深度,然后在显示24bit图片时就不会做lz所说的转化了。
不错不错,这几天试试就知道了。嘿嘿。 我要做S5pv210 24 bit 。 楼主上面代码也有线索了。
源码GPE EmulatedBlt_Internal()函数中可以找到):
 	while( height-- )
{
 	for( x=0; x<width; x++ )
    {
    	src.Value = ( *src.Ptr ) + ( *(src.Ptr+1) << 8 ) + ( *(src.Ptr+2) << 16 );
        src.Ptr += src.BytesPerAccess;
        if( pParms->pConvert )
        {
            src.Value= Parms->pColorConverter->*(pParms->pConvert))( src.Value );
        } 
        if( quickWrite )
        {
            switch(dst.Bpp)	            {
                case 8:
                    *(unsigned char *)dst.Ptr = (unsigned char)src.Value;
                    break;
                case 16:
                     *(unsigned short *)dst.Ptr = (unsigned short)src.Value;	                     break;
                case 32:
                     *(unsigned long *)dst.Ptr = (unsigned long)src.Value;
                     break;
                case 24:
                     *dst.Ptr = (unsigned char)(src.Value);
                     *(dst.Ptr+1) = (unsigned char)(src.Value>>8);
                     *(dst.Ptr+2) = (unsigned char)(src.Value>>16);
           }
           dst.Ptr += dst.BytesPerAccess;
       }
}
}
}
还有下面两个人的总结也非常有用 在EmulatedBlt_Internal()函数中加个Sleep(1000)的话,挺有意思,可以很清楚得看出WIN是如何显示界面的,包括像关闭的那个"X",是一个点一个点出来的),视频就不清楚了。 解决显示慢的问题,保证图片颜色深度和屏实际的一致,否则系统会做转换,这肯定是慢的,我们6410的CPU都是一样。 解决显示时间不一致的问题,双缓冲,用GDI来做就是,先把所有内容绘制到内存DC,在一次性从内存DC拷贝到屏幕DC,这样的效果就是同时显示出来的。 本人就是遵循这2点,所以我做的每个界面,显示速度很快,基本上是一瞬间就出来,而且是同时显示,不会局部不一致,闪烁什么的
guo100136017 2010-12-31
  • 打赏
  • 举报
回复

我也曾遇到该问题 花了2个月才解决 ,zhuEvan 如有兴趣可以聊一下
qwqwqw408 2010-12-27
  • 打赏
  • 举报
回复
解决显示慢的问题,保证图片颜色深度和屏实际的一致,否则系统会做转换,这肯定是慢的,我们6410的CPU都是一样。
解决显示时间不一致的问题,双缓冲,用GDI来做就是,先把所有内容绘制到内存DC,在一次性从内存DC拷贝到屏幕DC,这样的效果就是同时显示出来的。

本人就是遵循这2点,所以我做的每个界面,显示速度很快,基本上是一瞬间就出来,而且是同时显示,不会局部不一致,闪烁什么的
robin41209 2010-11-04
  • 打赏
  • 举报
回复
来领可用分,咳咳
yangky281 2010-11-04
  • 打赏
  • 举报
回复
怎么看都不知道是啥 不过还是支持一下
lukkqq 2010-11-04
  • 打赏
  • 举报
回复
值得学习下!
sky626095364 2010-11-03
  • 打赏
  • 举报
回复
ghjgyj
Margriet 2010-11-03
  • 打赏
  • 举报
回复
有用,十分感谢分享
zhuEvan 2010-11-02
  • 打赏
  • 举报
回复
[Quote=引用 70 楼 panzhx 的回复:]
引用 67 楼 zhuevan 的回复:
怎么都没啥人讨论呢
看来32BPP的市场需求还不是太大啊


我觉得现在很少人搞32BPP的,是因为32和16的显示效果差别不大,可能大多数嵌入式设备的屏幕比较小。可能屏的因素影响更大一点。当然如果分辨率较大的话SVGA以上的,色深影响就明显一些。
[/Quote]
要提高到32BPP,主要是因为16BPP下我们做的图片显示出来会有色块,据说是LCD屏的原因,提到32BPP就不会有了。
zhuEvan 2010-11-02
  • 打赏
  • 举报
回复
[Quote=引用 69 楼 panzhx 的回复:]
“"是要显示的数据到显存这边就不同了",GPE中从内存到显存传输的时候是以像素点来计算的,不是内存拷贝”

——你举的例子,只是其中一个的函数而儿。bmp画图也有写点的方式和内存拷贝方式。如果是视频,更不可能想你所说的一个点一个点的写。

sm502的驱动是 同事用来实现camer的视频叠加和双屏显示。不过我也研究不深,大概了解了一些。
[/Quote]
恩,应用层是我们老板做的,使用GDI接口来显示BMP图片以及其他控件,我按GDI接口的流程下来,就是按点来写的(包括系统的图标等等也是使用GDI接口来显示的,在EmulatedBlt_Internal()函数中加个Sleep(1000)的话,挺有意思,可以很清楚得看出WIN是如何显示界面的,包括像关闭的那个"X",是一个点一个点出来的),视频就不清楚了。
sm502,没板子,没的玩
zhuEvan 2010-11-02
  • 打赏
  • 举报
回复
人人有份
分少点,勿怪
zhuEvan 2010-11-02
  • 打赏
  • 举报
回复
暂时告一段落
不是十分满意,结贴给分
董小尾 2010-11-02
  • 打赏
  • 举报
回复
很有深度的帖子
knight31318 2010-11-02
  • 打赏
  • 举报
回复
wince 好用还是LINUX好用啊
buwanwow 2010-11-02
  • 打赏
  • 举报
回复
不懂,哈哈
jw212 2010-11-01
  • 打赏
  • 举报
回复
难得上次头版,没搞过,学习一下
bbtry 2010-11-01
  • 打赏
  • 举报
回复
这个学习一下
卓卓有余 2010-11-01
  • 打赏
  • 举报
回复
[Quote=引用 67 楼 zhuevan 的回复:]
怎么都没啥人讨论呢
看来32BPP的市场需求还不是太大啊
[/Quote]

我觉得现在很少人搞32BPP的,是因为32和16的显示效果差别不大,可能大多数嵌入式设备的屏幕比较小。可能屏的因素影响更大一点。当然如果分辨率较大的话SVGA以上的,色深影响就明显一些。
加载更多回复(56)

19,498

社区成员

发帖
与我相关
我的任务
社区描述
硬件/嵌入开发 嵌入开发(WinCE)
社区管理员
  • 嵌入开发(WinCE)社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧