在主界面上叠加透明窗口自己管理，风险太大

       视频监控软件智能分析模块需要优化，用户在录像播放窗口上画规则框，线或者多边形，然后选择对应的算法，规则框指定的区域按算法来分析，当有图像变动时会平台触发一个告警，然后该告警会抛到客户端，做出提示。由于以前画规则框的算法有问题，导致画线的时候效率奇慢，总是一卡一卡的，易用性很差。以前的同事撤出项目做IPTV了，最近优化这个画图的任务落到了我的头上。

         我看了一下以前的方法。以前是在录像播放窗口上叠加了一个从cbutton派生过来的子窗口，当用户拖动鼠标在播放窗口上画图时，首先在内存dc里面画图，然后将该位图传到cbutton中，然后drawitem中得到该位图，用原图做mask,对图像做各种与，或，异或操作，生成一副只有蓝色规则线，其它部位透明的位图（是图像算法吧，这块我没看太懂），并跟据该位图创建一个rgn，再将该Rgn指定成一个窗口，由于蓝色规则线之外都是透明部分，所有看上去规则线就好像画在录像上。然后问题来了，在跟据位图创建rgn时，需要把位图元素都获得，现有的方案是获得位图的宽和高后，用两层循环一个一个的扣点。这样在动态计算播放窗口大小后，就算是在1024*768下面也有3百多*2百多，将近7万个点，即是7万次的循环操作。若是只需要计算一次就无所谓了，但是每次画图时都需要当次传入的原图做为mask，然后在drawitem中响应，这样就卡得蛋疼了，可能你看见屏幕上出现第一条线，到下一条线出来的时候，这中间都过了十几秒了。这个产品能不能拿出来卖钱，十有89就会因为这一块的问题给废掉。

      补充一下， 这中间有个问题不能忽图略，为什么以前的同事要搞这么复杂，不直接画在录像窗口上，而要搞一个cbutton呢？因为录像是实时码流传输的，在录像窗口中会一直刷新显示。而规则务必要一直显示在录像上层，否则会画一下，然后马上又消失了，这样用户才能知道当前画到哪，还要不要继续画了。而且还有一些其它的功能，需要操作规则框，比如说选中，拖动，删除等等。即是说，录像和规则肯定是在两个图层上面的。

     当时拿到这个任务哥们立即就傻了，在南京的时候哥手上还有两个其它模块，这块老大要交给我，我拼命给推掉了，现在工作交接了，以前的模块给别人了，这个优化我也没有借口了，木有办法。

    当时有个想法是用一个前台透明窗口来实现，只需背景色透明，保持在录像播放窗口之前即可，其它的问题我也没有考虑太多，花了两天搞了个demo看了下，这个功能确实是可行的，于是就决定了这样来弄。把透明窗口放在录像前面比较好实现，很快我就能看到效果了，用透明窗口来现的话，由于只涉及到位图拷贝，不需要挨个扣点，效率跟以前比确实是提高了不止一个档次。而且其它所有的功能也可以正常使用。当时以为可以松口气了，就随意的摆弄了几次软件，发现了一堆问题，是UI方面的问题。

比如说：

        当我最大化，最小化主窗口的时候，这个透明窗口会一直呆着不动，这样就很奇怪了，你会发现在录像上画的规则框或许跑到其它的按钮，工具栏上面去了。

        当我移动主窗口的时候，可以把透明窗口放在主窗口外面。

        录像窗口是在一个表单视图中，当我拖动滚动条时，这鸟玩意没反应，反正一切跟onsize有关的操作都有异常。然后我就花了一周的时候来手动控制主窗口onsize 时透明窗口的行为，当窗口边界各种拖动时透明窗口的尺寸变化。这个计算坐标的过程花了我一周的时间，后面又遇上了各种希奇古怪的问题。比如拖动滚动条时界面有黑线（这个问题当时我脸上也有黑线了），后面用InvalidateRgn来更新其它的区域。

       虽然这个方法可以在一定程度上优化画规则效率，但是自己控制窗口行为的操作始终不如windows自己管理来得安全。倘或有一点问题未及时发现而出现了UI异常的问题，那我心理难安啊。如果真用了我的方法，会给以后维护代码造成了不小的难度，尴尬啊。