效率很高，但是部分效果很惊悚。
推送到了 pixi 分支：https://github.com/Hozuki/Bulletproof/tree/pixi。
效果请展开查看。
Visual Studio 2015（自带 IronPython 和 Python Tools for Visual Studio）在上一篇日志中的同一个测试下表现很好。
嗯，不过对于即时的键入，和内置方法的完成有点缺陷。例如同一个示例，如果我在后面新行输入“ur”，PyCharm 会提示输入“url”，但是 VS 没有反应；PyCharm 会内置一些方法数据，如 __INIT__、__ADD__，VS 没有提示。
9月17日凌晨的脑洞，有可能能优化 Canvas2D 版的实现
按照杨彦君的提议，如果支持 CSS Shader（现名 CSS Custom Filter）的话，应该可以大大减轻绘制的工作强度。
但是实际应用中，上面的文章中的示例根本没有起到效果。查看元素发现，-webkit-filter: custom 被自动禁用了。
有人尝试用 WebGL 计算 CSS Shader，不过很不幸，其中需要用到 html2canvas，而且只能进行静态的渲染（也就是说，渲染是手工控制的，不是应用样式后自动进行的），改变一下 DOM 元素就知道，完全是图像平面的顶点/贴图变换。
话说 CSS Shader 是有安全问题的。一封 WebKit 开发组的邮件表明，Chrome 很久之前就已经不再支持相当部分的 CSS Shader 了。
本来这个草案是由 Adobe、Apple 等联合提议的。Adobe 还专门有介绍提议的文章和介绍 CSS FilterLab 的文章（CSS FilerLab 是 Adobe 用于测试开发 CSS Shader 的网页工具）。CSS FilterLab 里面的工具链接早已跳转到其 GitHub 页面。而这个项目的状态看起来不管是代码更新还是 issue 都停留在了两年前。
真是悲惨。想到还是得用 Three.js 我汗毛都立起来了。
今天被学校的一个小工具折腾得不行，想自己写一个（毕竟都知道原理了）。打开 Visual Studio，映入眼帘的是刷新的新闻。9月3日发布，过了快两周我才看到……
MSBuild 三月开放了 GitHub repo，现在已经得到了大量的社区支持。下一步 MSBuild 就要开始跟着 .NET Core 跨平台了。由元数据（metadata）驱动（毕竟 CLR），MSBulid 本来就有良好的依赖管理能力（不用像 CMake 那样手工写一堆），而且充分利用多核处理器（这个或许 CMake 有，我没关注过）。微软计划将为其添加云构建的支持——很令人兴奋，如果和 .NET Native 技术结合的话对于应用而言编译就成了轻松快捷的事情——虽然我在想应用到大型软件上效果也会不错的。
很久以来微软都被开源社区（主要是某些 hardcore 的 geeks）称为 M$，博导也一直叫我“不要被M$控制，快跳到 Linux”。自从 .NET Core 和 BCL 宣布开源之后，微软给人的印象是越来越好了。
叫嚣“M$”的人，否定了他人的选择权利。你用 C++ 和 Python，我偏爱 C#；你喜欢命令行，我认为 GUI 比较便利（又不是不能用 CLI）。有错吗？为什么要歧视呢？就和几乎被所有人鄙视的 Visual Basic（我指的是 VB .NET 之前的 VB），都其实能做一些很漂亮的 hack，只不过异常晦涩难懂罢了。CLR 上的语言照样可以写操作系统。
Mono Project 的苦战也好，微软在趋势冲击下的拥抱开源策略也好，都是值得称赞的。
Bulletproof 的 SVG-Canvas 融合测试不那么尽如人意，测试分支在 https://github.com/Hozuki/Bulletproof/tree/deprecated-svg-canvas。
晚上开了一下脑洞，从最基础的 JavaScript Image Processing 开始找起，发现了有趣的东西。性能瓶颈有可能可以突破。具体等待明天（今天？）实验，然后将过程与结果记录下来。
VS Code 尝试，与代码重构（算得上么）时发生各种事情，追根溯源看的 TypeScript 编译
滤镜在 Bulletproof 中的应用，算法选用
即将完成的发光、模糊滤镜与灵感来源
睡前来一发，写了简单的 MotionGroup（忽略了 easing 函数，暂时只实现线性——其他的其实在函数库有了，处理再说吧，反正要睡觉了）。
于是可以流畅运行小圆脸和绿坝娘的demo了。
效果（GIF）请展开阅读。
解决了之前重绘重影、效率低的问题；对 VS+NTVS vs. WebStorm 的评论
程序结构更新后出现的问题与测试数据