有40多个图层(屏幕大小,2500*2500),用户可选任意多个图层同时进行缩放/旋转/平移,可以拖动鼠标看到预览效果。图层之间有不同混合(blend)模式,所以在缩放/旋转/平移后,还要进行混合。现在在64bit Windows上所有数据都在内存中,用纯CPU实现,感觉很卡. 
先不考虑混合的速度以及真正的变形,只考虑生成预览图, 如何让缩放/旋转/平移更快。 FBO 会好吗?最好也能在32bit Windows上流畅运行, 假设显卡很好吧。(能适应一般显卡更好)

解决方案 »

  1.   

    并行进行,用OpenMP试试看
    http://blog.csdn.net/fengbingchun/article/details/6531695
      

  2.   

    大伙给个思路:如何用GPU? 下面思路对否?
    for(i=0; i < 40; ++i)
    {
         1.Create Texture
         2.Copy Pixel to Texture
         3.Create FBO
         4.Copy Texture to FBO with Rotate/Scale Matrix
         5.Read Pixel
         6.Do blending. 
    }
      

  3.   

    GPU
      

  4.   

    把算法分成操作、计算和显示三个部分:
    其中操作层用来做用户交互,只处理这一个层加一个背景,而且不用插值,保证速度。
    计算层:在用户设定完参数之后,对当前图层按最终质量进行运算,这个算法的速度可以稍慢,但质量要求高。
    显示层:在每一次用户进行操作后调用 ,从后向前读取层数据,并且绘制到一个图像控件上,用为显示用的数据,用户在其上进行屏幕放大、缩小和平移。
    你说的旋转、图像缩放、Blend 等算法都是放在计算层中,根据用户的命令进行调用。
      

  5.   

    这么大的分辨率,这么多的图层,还有ALPHA混合,还有缩放旋转平移,这些都是GPU的拿手绝活,怎么看都非GPU莫属。果断D3D/OPENGL去。牛叉如FLASH的软件也架不住啊,CPU老高了
      

  6.   


    我们自己写ALPHA混合, 所以只能让GPU做缩放旋转平移. 我用FBO + Texture 试了一下,的确比用CPU快多了。 但如果显卡不支持FBO,或显卡很衰咋办?
      

  7.   


    用户可以选任意多层进行缩放旋转平移。 图像金字塔是个好主意, 比如8000x8000的图层大小, 缩小时,取4000x4000, 或2000x2000的图,可减小IO. 
      

  8.   

    本来显卡挫不挫、到底有多挫并不是你要考虑的事情,这些事情如果在WIN平台上的话,MS已经替你考虑过了,你的软件要真是想做得那么通用以至于不得不考虑显卡种类和性能的情况下,你要干的活就多了(工作量比你想象的还要多出一个数量级),显卡厂家类型、是否支持3D、支持3D的哪些特性、支持到什么程度、如果支持你该怎么做、如果不支持你又该怎么做万一全部不支持,我TNND的全得用软件实现一遍,即使全用软件实现,我还需要考虑是不是用多媒体指令优化一下?如果要优化,我还得判断CPU是否支持MMX/3DNOW?支持到哪一个层级?完了,每一个层级又是各一套不同的代码楼主,你这是找罪受呢,还是找罪受呢,还是找罪受呢?我明白了,估计楼主志向高远,立志再实现一套类似D3D的引擎,那我上面说的话全是多余的,就当我没说好了。如果不是,你还是听我的建议直接用D3D/OPENGL吧,别硬撑着钻死胡同了。你的所有问题别人都已经帮你想过了。你的这几个需求实在是太太太太过于普通了,不说现在很难找到很挫的显卡(现在最烂的笔记本所用的集成显卡基本都能实现这点需求),即使确实存在完全没有硬件加速的显卡,还有最后一招,D3D为你提供了软加速设备,全用CPU模拟GPU实现,内部有MMX加速的哦亲,比你自己实现的MMX加速还加速的哦亲^_^最后,你那个图像金字塔的概念,如果我没理解错的话,在行话里叫做MIPMAP,意思就是你创建一个纹理,系统能自动帮你生成一个纹理金字塔,比如64*64的纹理,就自动生成64*64、32*32、16*16……1*1的各种规格纹理,在贴图的时候系统会帮你选择最合适的纹理哦亲,全自动的哦亲以上话糙理不糙,无论是否有用,请授予我一面“节操爆表”的锦旗哦亲
      

  9.   


    谢谢如此详细的解释!我的图层可能是10000x10000大小, 如果全交给OpenGL去生成mipmap,担心它受不了. 在32bit OS上本来可用内存就不多,不想让OpenGL占用太多. 我自己做了内存管理和Paging. 因此, 我必须先用CPU把图缩小,再给GL. 不知有木有更好的办法? 
      

  10.   

    纹理过大的问题很好解决,拆分成若干个小纹理,贴图时无非是增加了几个顶点数据而已。你可以估算一下,生成MIPMAP,内存总数不超过原始纹理内存的两倍,而且所有纹理数据都是保存在显存里的,不占用系统内存。如果实在是显存太小,通过时间换空间(增加IO次数)的方式来解决,无非是渲染效率有所下降。
      

  11.   

    如果有40个10000x10000的图层,即需要4G空间. 32bit OS最多有2G内存可用,即要调2G到磁盘,如果交互时,鼠标每动以下就调一次,那肯定要卡死了。 
      

  12.   

    好吧,听到你的无耻需求,我投降了,锦旗也不要了如果我是你,遇到这种情况,我会裸体空翻1080度冰天雪地跪求老板:“您大人大量,给我配一台专业显卡吧,不贵,也就十来万或者您收购ADOBE公司也成,我去当个扫地的”
      

  13.   

    重新看了看顶楼内容,彻底崩溃,需要4G内存的图像居然还幻想着用CPU来运算,连GPU都跪地求饶了
      

  14.   

    对了,就是要想达到PS那样的处理能力。 不过在交互时,只生成Preview,完全可以做假的,图片可以粗糙些,Blend要对!我想PS也应该做了金字塔,可能还针对不同的CPU/GPU做了优化。 "收购ADOBE公司"也是一个不错的选择,考虑过
      

  15.   

    不好意思计算错了: 10000x10000 4通道的图片占400M左右内存, 40个图层需要16G左右的空间. 
      

  16.   

    400M显存,通常的显卡也能满足,但是16G,目前还没发现有哪款消费类显卡有这么大显存的。在显示和操作层面,还是先把图像缩小再变成纹理吧,屏幕也没有这么大的吧,至于最终渲染,完全不用考虑实时性能,增加IO次数一次一次把纹理送进去,还是能生成最终高精度图片的
      

  17.   


    谢谢, 我们已用SSE做Blend,并正在提速.
      

  18.   

    谢谢大家的建议. 只生成可见部分,并实现自己的Mipmap/LOD,在Zoom out (缩小)情况时,效果还不错.Zoom in (放大,比如100%, 6400x6400x40图层)时还是有些慢,不过Photoshop 7也不快.