Jim Chen

另外吐槽一下，明明BAS应该是“比以前安全”的脚本语言，毕竟整个语言都是自己写的解析器。但是看一下issues就能发现都是好多初级BUG和漏洞，完全没考虑过做好安全的，实在是无法直视。

哦对，BAS有这个实现（虽然已经不搞了）：https://github.com/hozuki/sebas

> 另外dplayer我感觉是，目标是模仿yt，但是细节还没模仿到位，就会有一种很微妙的感觉 界面会让人有一种这里应该有这个功能的期望，但是没有实现，会形成一种落差 好用就是啦~。。。我就不说有多少人问过 “欸，CCL怎么设置视频地址” 这种类的问题了。。。而且感觉比我那个为了demo CCL做得ABP强的还是（其实是先有的ABP。。）

更换了引擎，修正了无数BUG。

有这个打算。还有一个设想是，在加载的时候先在本地浏览器上测一下各种常见字体的常见字符的宽度（好像西文用em法可以测），传到沙箱里面，之后的估算就能稍微准确一些了。唉，Kerning 这东西一直比较奇妙，系统和浏览器给的API都太少。

主要是客户端经常容易没字体，然后浏览器就随便fallback到了一个什么乱七八糟的字体上，然后就有可能BUG掉。不过其实这种边角case反正是估值也就随便了。 还有印象里，好像 SimHei 和 SimSum 对西文也都一视同仁的变成等宽？

> 所以必须每一次都测。不能用 length \* pixelheight 。 所以说主要要看标题，目前的设计是必须估算的，因为不能每次测（架构上不允许，因为不能预判代码）。最多就是在最开始测一遍英文字母（单非等宽字母而已，自然不完整因为没法准确测量kerning），然后对中文采取长宽估算。即使不直接乘法（这个连换行都没法处理→_→），估算只能使用常量数据（虽然这些常量可以在引擎启动的时候传入）。 本issue主要是研究到底怎么估算能最大限度的靠谱，比如即使差一个字宽也完全没问题可以接受。实际上只要误差能保证最大在一个百分比内就可以close掉了。 有关局限性的问题可以参考 `/docs/` 有关 scripting 的章节。主要原因来自非阻塞，简单来说参考如下代码： ``` JavaScript var c = $.createComment("Test", {}); c.text = "Testing"; trace(c.textWidth); ``` 实际上这段看似同步的代码，进行了两次异步操作： ``` JavaScript var c...

@Catofes 不不这是另一个Issue和之前不一样。textWidth 和 textHeight是 **代码弹幕** 的两个属性，相较普通的弹幕而言代码弹幕有更多的局限，还需要兼容代码弹幕开发人员的代码（和其中可能存在的各种BUG）。

> 如果这个写出来了preload上也可以用啊。性能提升还是很明显的。 以后说不定用纯CSS就能不用计算长宽了（或者长宽计算就不太影响了）。可以玩玩 dev-animations 分支，已经抛弃总定时器了。（虽然那样暂时会导致一些微妙的BUG，不过都是能修的）

代码吧，非常复杂，有的写法很好，方便优化，有的写法很糟糕，我就得改底层实现让它不是那么的糟糕。 说实话半年前我还认为根本不可能搞出代码弹幕呢。。。事实证明我错了。。。