我现在主要是用来显示视频。。。。考虑到将硬解码的视频传个GUI再去一帧一帧的去刷是不是比较不符合常规啊？这样效率太低了吧？一般大神们做的硬解码播放器都是怎么做的啊？是直接使用framebuffer还是传到上层UI啊？前提是保障流畅性。。。而且我这个还有摄像头实时预览的情况。。还有4宫格显示视频的情况。。
现在我暂时采用的是framebuffer。。但是framebuffer显示一个视频还好吧。。。如果是显示四个，弄一个四宫格，分别显示不同的视频。。那就没办法了啊？framebuffer是线性的区域。。。一整行一整行的存储的。。那四个格就打断了线性存储。。如何对这四个格对应的区域进行赋值显示啊？或者一般大家都是怎么显示这样的视频的？采用什么方法比较专业啊？
求大神现身说法！
------解决思路----------------------
这个需要硬件支持
如果硬件只支持提供一个线性区域，则只能自己写算法来分4块显示。速度肯定慢，因为压力全在CPU上。
如果硬件支持通过设定某些特殊寄存器而把一些区块临时合并成一个小的连续内存访问区域，则通过这种映射的办法可以做到分成多块高速显示。这实际上是把计算压力压向硬件。
当你面临这个需求时，复杂度就已确定了。不能消灭复杂度，只能转移它。
这就是为什么现在电脑都配独立GPU，GPU就是把图象功能抽象出来，转移CPU的压力到其自身上。
------解决思路----------------------
我一下子想起来了Android系统中实现的方案，它完全不会去动驱动中的任何东西。把FB看成一个画布，按照大小分4块A B C D，A B C D分别当时一个单独的小的画面，分别的进程去操作它，将要显示的内容填充进去。然后将A B C D合并到一个画布上，填充到FB中。这样就实现了你的需求。换成Android中的话就是每个APP都是一个surface，各自尽情地绘制自己的界面，最终将这些个suface合成在一起，很典型的比如调出输入法的时候其实是APP 和 输入法APP都在前端显示，它们是两个不同的surface。它们之间的合并还是叠加性质的，你要实现的其实更简单，仅仅是像「拼圆」一样拼接在一起。
倒着看世界，一切都好办。
------解决思路----------------------
struct fb_var_screeninfo {
__u32 xres;
__u32 yres;
__u32 xres_virtual;
__u32 yres_virtual;
__u32 xoffset;
__u32 yoffset;
__u32 bits_per_pixel;
__u32 grayscale;
struct fb_bitfield red;
struct fb_bitfield green;
struct fb_bitfield blue;
struct fb_bitfield transp;
__u32 nonstd;
__u32 activate;
__u32 height;
__u32 width;
__u32 accel_flags;
__u32 pixclock;
__u32 left_margin;
__u32 right_margin;
__u32 upper_margin;
__u32 lower_margin;
__u32 hsync_len;
__u32 vsync_len;
__u32 sync;
__u32 vmode;
__u32 rotate;
__u32 reserved[5];
};
不知道
__u32 left_margin;
__u32 right_margin;
__u32 upper_margin;
__u32 lower_margin;
能不能满足你的需求
------解决思路----------------------
别那么早就是想着fb，在最后关头才是它。以下是Android的实现框架，供你参考：
------解决思路----------------------
还有一张图：
