zoukankan      html  css  js  c++  java
  • 前一阵子跟人谈多分屏桌面展示

    前一阵子,在一个很特殊的情况下,和别人谈论多分屏桌面展示的问题。
    以前没做过,突然想到的两个方案。
    多少分屏算多呢,实际上那些家伙弄得是4*4 的16分屏。(具体像素未知,但是他们做的是16分屏。)
    那些家伙做的是全球数据展示,做全球数据收集,定时每秒在4*4 的大显示器组上显示最后5 条数据在世界地图上的的位置。
    当时谈到这个问题的时候,我的第一个想法:
    首先弄一台PC机,作为主机,在其内存中做一张超大的图片,然后逻辑上等分4*4 的16份,分别编号,
    再弄16台PC机,或者移动设备,作为工作机,分别编号与主机内部的编号对应,
    通过某些手段,比如网络通信,串口通信等等手段,把主机上面处理了之后的图像根据编号直接发送到每一台工作机上,
    工作机再把数据分别写入自己的显存中,然后直接从显示设备上显示出来。
    然后他们说,我的想法不好,这样的话,还需要一个同步的过程。
    我不清楚为什么需要同步,近距离数据传输,且是直接传输,客户机不需要做任何事情,只要监听设备,然后显示数据就行了。
    这种情况,甚至连操作系统都不需要,直接单片机就能解决问题,无非就是忙等数据,然后把数据写到显存中。
    比如arm contex a9 裸机,一个CPU 加上一个串口,加上一块LCD,就可以轻松实现这些,连个操作系统都不需要。
    功能单一所以肯定安全稳定,不需要操作系统所以一旦出现问题立刻就能清楚是哪里的问题。这种情况下,同步,纯属多余。
    不能否认,肯定存在一定的几率,哪里出现了一点点问题,会使得数据传输或者哪里哪里出现故障导致数据丢失或者延迟的发生等等。
    但是极近距离的话,串口的效率及稳定性都是超一流的,如果出现这种问题,就是设备问题,该换掉了。
    优点,便宜,维护方便。(串口裸板驱动不到200行代码,LCD显示器驱动不到200行代码,全部代码加起来估计可以不到1K,代码方面维护极其方便。)
    出现问题定位也方便,代码量极少,软、硬件方面的问题,很容易定位。(不是代码的问题,就是设备的问题,也有可能是宇宙射线的问题,这个不考虑。)
    (估计m 系列就可以了,用a9来跑这玩艺,真浪费。)
    但是那几个老大仍然对我的意见不依不饶,就是同步的问题,所以我考虑了第二个想法:
    这么大的工程,我想,主机的性能应该也是超级强的吧,是不是有可能主机上有16块显卡呢。
    这。看似比较好笑,但是实际上不是那么好笑。毕竟早就已经有了USB显卡了。
    如果真的主机上挂了16块显卡,那就是直接写显存的事情了。这就更不需要同步了。
    但是那几个哥们仍然不依不饶地问我同步怎么办。
    其实,这里,个人感觉,最麻烦的地方,应该是超大图片的无闪烁刷新,其他都不是问题。
    因为,只要颜色有变,就涉及到刷新,(即便颜色不变,也可能是在刷新,但是肉眼无法识别。。。)如果正在刷新,时间片没有抓好的话,就可能出现闪烁,这是最头疼的。
    同样的设备,同样的厂商,同样的型号,同样的代码,效率可能有波动,但是波动绝对不会特别大,所以只要各个方面没有问题,同步完全就是多余的。
    而且,16个显示器同时绘图,即便有同步,又能如何,有一个显示器没画完,主机在等它,那其他的显示器下一帧的图也不画了?

    硬防里面还跑linux呢,几十万行代码,数据进协议栈跑一圈,这种低效率的处理都耗不了多少时。
    (硬防如果耗时严重,客户端用户体验肯定成问题。但是不做硬防的话,服务段的抗击打能力肯定要下降。)
    1K来行代码的小设备还要同步? 
  • 相关阅读:
    RecyclerView 数据刷新的几种方式 局部刷新 notify MD
    【图片】批量获取几万张图片
    RV BaseRecyclerViewAdapterHelper 总结 MD
    RecyclerView.ItemDecoration 间隔线
    Kotlin【简介】Android开发 配置 扩展
    Kotlin 特性 语法糖 优势 扩展 高阶 MD
    一个十分简洁实用的MD风格的UI主框架
    折叠伸缩工具栏 CollapsingToolbarLayout
    FloatingActionButton FAB 悬浮按钮
    Glide Picasso Fresco UIL 图片框架 缓存 MD
  • 原文地址:https://www.cnblogs.com/suanguade/p/4037992.html
Copyright © 2011-2022 走看看