【讨论】Velocity.js 声称能加速JS动画，是否能提升CCL的性能？

[m13253]

丢个文章吧，文章结尾有介绍。
《CSS 和 JS 动画哪个更快》

julianshapiro/velocity 的简介是加速 JavaScript 动画，是不是真的能加速 JavaScript 动画呢？

不过我想 velocity.js 应该能自动开启硬件加速并且不需要因为 vendor prefix 而头疼了。

[jabbany]

看了，现在的问题主要不是播放的时候卡，是突然载入/删除大量弹幕会卡死，这个的话 RAF和硬件加速都没办法。RAF和硬件加速主要是帮助已经在屏幕上的弹幕能流畅的跑（顺便，之前CCL也有过用RAF，现在src/external 里面也有一个polyfill。但是正是因为 velocity里面提到的JQuery的决定才不用的，一个是带来的性能提升并不高，因为在进行DOM添加删除操作，不仅仅是移动弹幕，二者是屏幕失去焦点的时候 RAF就不跑了，这可不行）

对于DOM倒是有一招，就是把高密度弹幕预先载入，比如进入高能段之前，就先行载入弹幕，让 opacity 为 0，然后等时间到了，再放出来，这样均匀的载入弹幕，应该就不会出现卡死状况了。

Profiler上看的话很明显，如果没有弹幕的快速增减，帧数可以稳定在50-60fps。有的话，就直接掉到30fps以下了。

[m13253]

明白了。
不过优化要从两头来考虑，一个是宏观的算法角度，一个是微观的局部代码优化。

局部的代码优化，比如把

for(i = 0; i < a.length; i++)

改成

var cache_length = a.length;
for(i = 0; i < cache_length; i++)

是可以提升速度的。

算法方面，是否可以把即将要在同一秒内消失的弹幕放到同一个 wrapper div 里，到时间了把那个 wrapper 给 remove 掉可否？

还有，试试看 opacity: 0、-webkit-transform: scale(0) translateZ(0px)、-webkit-transform: matrix3d(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)、visibility: hidden 哪个更快。

不过，预先载入对全程高密度就无效了哇。虽然这样的情形比较少，但是没有足够理由无视这种情形。

[jabbany]

局部的代码优化

JS的话其实差不多，而且如果我没记错 length是静态字段。当然现在瓶颈是绘图，所以运算其实本身不太影响。

算法方面，是否可以把即将要在同一秒内消失的弹幕放到同一个 wrapper div 里，到时间了把那个 wrapper 给 remove 掉可否？

把它们放到这个DIV里面本身这件事就和都 remove 掉的复杂度差不多了。。。不过相比之下另一个方法是限制每一个周期的remove个数，等几个周期之后再remove掉就可以。（这么一说应该试试）

还有，试试看 opacity: 0、-webkit-transform: scale(0) translateZ(0px)、-webkit-transform: matrix3d(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)、visibility: hidden 哪个更快。

应该差不多快，因为更改CSS属性本身有一个比较大的代价。还有好像visibility不能用因为之后offset*就变成0了，然后空间排布器就挂了

不过，预先载入对全程高密度就无效了哇。虽然这样的情形比较少，但是没有足够理由无视这种情形。

我觉得全程高密度也没办法了，只能靠限制同屏弹幕。即使B站的Flash播放器全程高能也会卡（旧版，新版不知道，我觉得也会卡吧）。

[m13253]

在 2014-5-12，2:55，"Jim Chen" notifications@github.com 写道：

JS的话其实差不多，而且如果我没记错 length是静态字段。当然现在瓶颈是绘图，所以运算其实本身不太影响。

length是一个属性，不是静态的。因为解释器无法保证执行一遍循环体之后length不变，所以不可能帮你缓存。
昨天在一篇博客上看到经过测试，IE的length的时间复杂度是O(n)。
稍稍缓存一下能变成O(1)岂不是太划算？

昨天那个博客我找不到了，但是找到其它一些技巧 http://blog.segmentfault.com/skyinlayer/1190000000490324

[jabbany]

嘛，实际上没有区别吧，一共同屏也就 <200条弹幕，O什么都是常数水平了。还有 length作为属性也不用O(n)就可以实现的吧，只要每次resize array操作的时候变化相应大小就可以，然后存成指针这样不影响每次循环的读取，每次访问也能是O(1)的。当然IE我不知道，Webkit应该是优化了的，length的getter是普通的读操作，setter倒是O(n)的，因为可以截断Array。

今天Profile了一下，程序本身跑44s的时候，纯运算大概也就是 40ms。当然要是在做后端服务器（nodejs）我倒是能理解提高JS运算效率。

最大头的实际上是是计算DOM的 style，弹幕载入（添加DOM）总运算花了 6s，弹幕载出（删除DOM）总运算花了 4s，运动大概花了 2s。相比于计算和跑array的总（0.04s），差了两个数量级了。可惜这俩重头都没办法，添加DOM里面最耗时的是读取 offsetWidth/offsetHeight，因为会导致浏览器排版去专门计算这个数值（一旦访问过一次之后随后的访问都是瞬间的，因为会缓存（因为CCL会在style里面加入一个 width:固定住宽度））。其次就是添加Style和className设定。删除的时候最耗时的就是删除本身了。

[Catofes]

我试着预先加载几秒钟的弹幕到一个div 然后删除的时候直接删除div 。
不过没有实质解决问题，主要时间消耗到了 offsetTop. 也就是计算布局的时候，而且消耗时间很长。

要不就要手动写个根据字符数量算宽度高度的东西了吧

[Catofes]

手写了根据字符数量计算宽度高度的东西。。。

http://catofes.github.io/CommentCoreLibrary/demo/
不知道性能有没有提升。。。

[m13253]

手写了根据字符数量计算宽度高度的东西。。。

必然不靠谱。根据字符数量计算是完全不靠谱的。
Unicode compositing character 你考虑到了么？这种东西经常出现在颜文字里哇。
对于 SimHei，因为是等宽字体，（操），所以估算的结果还是蛮准的。

我的想法是，Webkit 是否会对 iframe 开一个新线程呢？如果那样，在 iframe 里算可以不？

[Catofes]

我不这么认为。

我觉得没有必要需要极其准确的给出弹幕的宽度和高度，因为这两个参数只会影响到弹幕的排布，也就是说如果这两个参数有问题的话最多是导致弹幕之间的不合理重叠或者空白。 而如果大部分都是偏差不大的话牺牲这点得到性能提升我觉得是可以的。

我猜flash中根本就没有像html一样的自动调整布局，原版弹幕播放器估计也是强算的吧。

[Catofes]

配合 video.js:
http://catofes.github.io/videojsABdm/demo/

测试截图：
https://lh5.googleusercontent.com/-N8ihiLKEsjU/U3N7PEDLKgI/AAAAAAACXSs/9CrHR07zRLs/s0/%E5%B1%8F%E5%B9%95%E6%88%AA%E5%9B%BE%28109%29.png

-感觉没变化。。。。AVG是cpu使用率吗？ 完全一致啊在windows下。 linux下还是有区别的欸

[m13253]

我猜flash中根本就没有像html一样的自动调整布局，原版弹幕播放器估计也是强算的吧。

Flash是可以获得长宽的，不需要强算。

-感觉没变化。。。。AVG是cpu使用率吗？ 完全一致啊在windows下。 linux下还是有区别的欸

AVG是平均值Average。

[m13253]

弹幕密度极限测试的话，可以试试这两个视频：
av124748 【呆又呆】鹿乃呆? 弹幕呆?
av332732 音乐视频-其他【弹幕的狂欢】威力加强版

[Catofes]

摊手
看不懂性能分析。。。
IE告诉我 新写的耗时最大的是 left 函数：

[m13253]

IE告诉我 新写的耗时最大的是 left 函数：

left是什么函数？如果你能告诉我我就不去读源码了。

[Catofes]

DOM.style.left="xxx px"
嗯 这货 就是DOM的内置函数

[Catofes]

极限测试果然叼炸天

[m13253]

DOM.style.left="xxx px"

嗯 这货 就是DOM的内置函数

@jabbany 我叫你用 transform: translate3d 你非不听

[Catofes]

主要是觉得不科学，毕竟left操作数量是一样的，操作函数是一样的，无非就是弹幕多套了一个div层，然后耗时就这么不科学了。。。

对比了一下 起码能播放了~

[jabbany]

效果一样的，反复通过js改css，改哪个哪个就是瓶颈。问题不在于改那个属性，是改的多频繁。
On May 14, 2014 10:55 AM, "Star Brilliant" notifications@github.com wrote:

DOM.style.left="xxx px"

嗯 这货 就是DOM的内置函数

@jabbany https://github.com/jabbany 我叫你用 transform: translate3d 你非不听

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-43090934
.

[m13253]

效果一样的，反复通过js改css，改哪个哪个就是瓶颈。问题不在于改那个属性，是改的多频繁。

明白了，原来到现在还没有用keyframe或者transition或者animation啊。

[Catofes]

所以说现在很奇怪，改得频繁数目基本一致，不过消耗的时间大概有5，6倍了

[jabbany]

应该是诱发reflow了吧。。。我印象里尽量避免reflow的。。。
On May 14, 2014 11:02 AM, "Catofes" notifications@github.com wrote:

所以说现在很奇怪，改得频繁数目基本一致，不过消耗的时间大概有5，6倍了

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-43092041
.

[jabbany]

keyframe没法通过js设定，还有根据@chitosai 测试过效果也不好。
On May 14, 2014 11:02 AM, "Star Brilliant" notifications@github.com wrote:

效果一样的，反复通过js改css，改哪个哪个就是瓶颈。问题不在于改那个属性，是改的多频繁。

明白了，原来到现在还没有用keyframe或者transition或者animation啊。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-43092005
.

[m13253]

keyframe没法通过js设定，还有根据@chitosai 测试过效果也不好。

不过我现在找到了用js停止transition的方法了。

[jabbany]

animation正在测试，不过根据velocity.js那篇文章的解释，应该不但效果一般，灵活性也不好（主要是暂停问题）
On May 14, 2014 11:02 AM, "Star Brilliant" notifications@github.com wrote:

效果一样的，反复通过js改css，改哪个哪个就是瓶颈。问题不在于改那个属性，是改的多频繁。

明白了，原来到现在还没有用keyframe或者transition或者animation啊。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-43092005
.

[jabbany]

对了接一下之前的，avg 是平均处理时间，即每一次刷新的实际耗时，以毫秒记，大于10。影响因素还包括浏览器的整体繁忙程度。max是最大处理时间，卡起来最厉害的一块占用了多久，fps是1000/avg。。。

[Catofes]

http://catofes.github.io/videojsABdm/demo/jixian.html 实在是欢乐～～

jabbany要不还是按我这样加一个预加载？ 对于如上这种及其蛋疼的弹幕还是很有效的？ 可以的话我去发pull request

[jabbany]

@Catofes 预加载的话还在研究，你这个是去掉了高度的读取吧。。。好像会产生BUG？

[m13253]

话说 visibility: hidden 真的无法读取高度么？我知道 display: none 无法读取，但是 visibility: hidden 是会排版的啊。

建议实验一下用一个单独的div来获取宽度高度。原来创建一条弹幕要对几百个元素reflow，现在只需要对一个元素reflow。
或者把舞台上所有弹幕根据消失时间排序装到sqrt(n)个容器div里。能减少reflow。
只是猜想，需要试验。

[jabbany]

bilisyndicate主要是搞代码弹幕（Mode8）的。。。但是好像Mode7的高级弹幕竟然也更新了

[TundraWork]

噗，那我再问问，主要B站我认识的码农作息时间和正常人类都不一样，现在联系不到

在 14/7/23，Jim Chennotifications@github.com 写道：

bilisyndicate主要是搞代码弹幕（Mode8）的。。。但是好像Mode7的高级弹幕竟然也更新了

---

Reply to this email directly or view it on GitHub:
#13 (comment)

[jabbany]

是啊是啊。。。我。。。也是个海外时差党呢→_→

[Catofes]

貌似没录好。。。recordmydesktop 不知道出啥问题了。。。反正正常看的时候没有哪些斜向的撕裂。不过卡顿程度应该可以从视频中看出来。
测试如下：
http://youtu.be/K3ZFz0WwLz4
显卡： AMD 6570M 也是开源驱动。感觉效率真的高了不少，一会儿去windows下IE测试看看

[jabbany]

嗯。。。我还以为我的显卡又挂了呢。。。

[jabbany]

我还有个dev-testing分支正在研究，不稳定，没测兼容性。基本策略是在每一次 time 的时候缓存本次需要添加的弹幕到一个documentFragment里面，然后一口气添加进去，之后一个个再排版。

感觉有时效率好有时不好的样子，也可能是我机子的问题。。。一直在用chrome的timeline测试，Test 9之前可以全程60fps（包括各种彩虹的添加删除），可是后来跑了一次就还是会出现阶段性掉到30fps以下，所以不知道是什么在影响。

[Catofes]

这个录的就是 dev-testing 分支啊？

不过真的没有搞明白dev分支的各种黑科技。大概看了看貌似定时器还在？然后改动的是css？

在 2014年7月23日 下午2:11，Jim Chen notifications@github.com写道：

我还有个dev-testing分支正在研究，不稳定，没测兼容性。基本策略是在每一次 time
的时候缓存本次需要添加的弹幕到一个documentFragment里面，然后一口气添加进去，之后一个个再排版。

感觉有时效率好有时不好的样子，也可能是我机子的问题。。。一直在用chrome的timeline测试，Test
9之前可以全程60fps（包括各种彩虹的添加删除），可是后来跑了一次就还是会出现阶段性掉到30fps以下，所以不知道是什么在影响。

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

乔颢 Catofes

浅草、洛水、冉枝。

GPG 公钥：http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF1EF10EDE6EA2EC

[jabbany]

哦。。。。原来如此。。。话说锯齿实在是挺严重。。。

[Catofes]

那是录屏软件的问题。。。。不知道为啥会出这问题。。。

不过现在感觉弹幕还原效果和Bili站上似乎也有一点区别，不过这种极限情况估计也没可能遇到的～

2014-07-23 14:34 GMT+08:00 Jim Chen notifications@github.com:

哦。。。。原来如此。。。话说锯齿实在是挺严重。。。

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

乔颢 Catofes

浅草、洛水、冉枝。

GPG 公钥：http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF1EF10EDE6EA2EC

[jabbany]

嗯，

• dev-testing : 不稳定的各种脑洞，属于瞻前不顾后的
• dev-scripter : 没搞定的有BUG的代码弹幕实现，和master共进开发，动不动觉得差不多了，就引入一下
• dev-animations : 使用纯CSS的尝试，未来会和 master合起来，用户可以选择用什么模式渲染，支持的东西不一样。当然得在 v1.0.0 的API确定后再说。现在API还混乱中呢。

[jabbany]

不过现在感觉弹幕还原效果和Bili站上似乎也有一点区别，不过这种极限情况估计也没可能遇到的～

写这个库的时候到现在B站播放器至少改版了两次（其中一次更新了弹幕排布算法）。。。CCL一直没改版，所以逐渐就不一样起来了，倒是兼容旧的弹幕兼容的比新版B站播放器要稍微好一些。。。

[Catofes]

试着用Canvas处理横向普通弹幕，感觉效率提高了不少啊～～ 起码在移动设备上观看压力不是那么大了。

测试如下：N5 不过因为没有其他摄像设备，所以录屏会带来一定的卡顿。然后对比的是现在的gh-pages分支。不知道有没有上黑科技～～
https://www.youtube.com/watch?v=tEATx3rJeKA

以及另外一组测试：
https://www.youtube.com/watch?v=jfbhEBXABJ0
https://www.youtube.com/watch?v=MoBlpIompXc

[Catofes]

/********************
好吧呀。。 我放弃了。。。。。。

出现了以下坑爹的情况。Canvas绘制文字的效率不是那么的高，但是他绘制文字边框的效率更差。于是乎，没有文字边框的时候。IE流畅的不得了，serface pro cpu占用超低，然后绘制边框cpu就从18%-》40%。。。原来的只有25%左右啊。

然后更奇葩的是。Chrome各种黑科技，也在Surface Pro上测试 18%左右的cpu占用。。。

总之现在勉强能用，可以看看有没有更好的性能改进。 其次排版估计还要调整，尤其是有换行的排版。简直不能看。
*************************/

换了一种buffer的方式，现在IE怒干沉chrome～ cpu占用低于10% ， 23333累死我了。 不过bug估计还是一堆。。。

代码：https://github.com/catofes/CommentCoreLibrary/tree/gh-pages
测试： http://catofes.github.io/CommentCoreLibrary/demo/
配合videojs：
http://catofes.github.io/videojsABdm/demo/
http://catofes.github.io/videojsABdm/demo/jixian.html
http://catofes.github.io/videojsABdm/demo/jixian2.html

[insionng]

@Catofes http://catofes.github.io/videojsABdm/demo/jixian2.html 此弹幕如此高密居然很流畅啊,这些改进有无合并到主线的?

[jabbany]

@insionng jixian2主要是把滚动弹幕放到了canvas里面（canvas是直接绘图、渲染的速度几乎不受弹幕数量的影响，但是为此也要有一些牺牲。）

最新版本的CCL支持多源渲染了，合并到主线应该会容易很多。要是 @Catofes 有兴趣可以试试，只要做一个 CanvasComment 之类的 extend CoreComment，重制一下 update() 函数和 width/height 读取器就可以了。可能会用 .parent.stage 绘图等等。

个人设想CCL里面还可以加一点逻辑判断：比如如果同屏弹幕密度高于某某数值的话就开始写到 canvas 里面而不再使用DOM，当数量降低了就回到用DOM。因为有抽象弹幕对象，所以空间规划器内两种弹幕还依然可以一起规划，不会冲撞。

至于 DOM 弹幕本身，现在也有设想把 dev-testing 里面批量添加的一些性能改进引入到新版。

[insionng]

@jabbany 你好啊..目前感觉你开了非常多的探索路线,这么多分支路线会不会让你精力过分分散了?

昨天一晚都在测你们两人的不同版本,发现在高密弹幕下,官方版出现几次卡顿,但jixian2居然很流畅,偶尔会出现一下,但一下就过去了,估计是那个弹幕的确太高能,谁都无法幸免.

对于普通用户而言,他们可能分辨不出这两个库之间的实现方式牺牲了什么,只是知道哪个不卡哪个会卡.哪个兼容性好哪个兼容性不好.

以上是肺腑之言..

另外有个疑问,弹幕读取的是一个弹幕xml文件,我疑惑的地方是,如果我发送弹幕,弹幕是服务器收到后写入这个文件吗?然后,播放器应该也无法实时的显示出刚刚发送的弹幕吧?

我应该怎么一个思路去做才能让弹幕也是实时显示出来?

目前是videojs+CommentCoreLibrary

[Catofes]

赞！ 新版本出现了？ 我去试试看。

现在的canvas渲染是有牺牲的，牺牲了还原的精确度。我觉得多试试看调整之后效果估计会更好。
2014年9月27日 上午6:25于 "Jim Chen" notifications@github.com写道：

@insionng https://github.com/insionng
jixian2主要是把滚动弹幕放到了canvas里面（canvas是直接绘图、渲染的速度几乎不受弹幕数量的影响，但是为此也要有一些牺牲。）

最新版本的CCL支持多源渲染了，合并到主线应该会容易很多。要是 @Catofes https://github.com/Catofes
有兴趣可以试试，只要做一个 CanvasComment 之类的 extend CoreComment，重制一下 update() 函数和
width/height 读取器就可以了。可能会用 .parent.stage 绘图等等。

个人设想CCL里面还可以加一点逻辑判断：比如如果同屏弹幕密度高于某某数值的话就开始写到 canvas
里面而不再使用DOM，当数量降低了就回到用DOM。因为有抽象弹幕对象，所以空间规划器内两种弹幕还依然可以一起规划，不会冲撞。

至于 DOM 弹幕本身，现在也有设想把 dev-testing 里面批量添加的一些性能改进引入到新版。

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

[Catofes]

啊对。一般电脑都足以应付普通弹幕。 canvas版本实际上是想用于移动设备的。 毕竟cpu占用少可能省些电而且流畅。
2014年9月27日 上午7:09于 "Hao Qiao" 1993422qsh@gmail.com写道：

赞！ 新版本出现了？ 我去试试看。

现在的canvas渲染是有牺牲的，牺牲了还原的精确度。我觉得多试试看调整之后效果估计会更好。
2014年9月27日 上午6:25于 "Jim Chen" notifications@github.com写道：

@insionng https://github.com/insionng
jixian2主要是把滚动弹幕放到了canvas里面（canvas是直接绘图、渲染的速度几乎不受弹幕数量的影响，但是为此也要有一些牺牲。）

最新版本的CCL支持多源渲染了，合并到主线应该会容易很多。要是 @Catofes https://github.com/Catofes
有兴趣可以试试，只要做一个 CanvasComment 之类的 extend CoreComment，重制一下 update() 函数和
width/height 读取器就可以了。可能会用 .parent.stage 绘图等等。

个人设想CCL里面还可以加一点逻辑判断：比如如果同屏弹幕密度高于某某数值的话就开始写到 canvas
里面而不再使用DOM，当数量降低了就回到用DOM。因为有抽象弹幕对象，所以空间规划器内两种弹幕还依然可以一起规划，不会冲撞。

至于 DOM 弹幕本身，现在也有设想把 dev-testing 里面批量添加的一些性能改进引入到新版。

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

[insionng]

@Catofes 噢明白了,你也好早啊...用于移动设备这个考虑很好,我的小站目前也是对移动端也有自适应,要是用canvas版,那么两个平台播放都没问题了.

[insionng]

@Catofes 对了,顺便请教你一个问题,知道videojs播放器怎么连续播放2个或以上的视频?譬如优酷的视频有些是分成几段落的.

[Catofes]

考虑过 ， 估计无解。。。。 除非完全手写。。
2014年9月27日 上午7:43于 "insion" notifications@github.com写道：

@Catofes https://github.com/Catofes
对了,顺便请教你一个问题,知道videojs播放器怎么连续播放2个或以上的视频?譬如优酷的视频有些是分成几段落的.

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

[jabbany]

@insionng

其实CCL的基础方向是兼容性、还原度和简便性，所以每个 release 都是会保证不能降低兼容性和还原度的前提做的 。master 分支的代码一般不轻易更新，更新后也会留一个缓冲期让大家测试BUG再发 Release 推到 NPM跟Bower目录里面。鉴于此，在近期 CCL 的 master实现都会采取主要以 DOM 为主的还原度优先开发模式。

每一个release都要经过相当的回退测试，尽量保证不会比前一个版本在兼容性和还原性上差，所以可以放心用。dev-分支里面就没有这个保证了。

与此同时，新的技术总要尝试，包括DOM带来的性能问题也要解决，所以 Canvas版本也在研发、CSS3版本也在尝试，等解决了Canvas 的弹幕高度检测BUG后，等解决了CSS3的暂停和跨浏览器限制后，新的效率高的技术就会代替旧的纯DOM技术。新的技术有的时候会让以前渲染的挺好的东西坏掉，有时二次开发可能希望牺牲还原度或者兼容性来换取效率优势，那么就可以尝试其他的dev-分支。

有关实时弹幕

实时弹幕实际上是开放支持的，但是不是通过默认的 load 。目前版本可以动态 insert() 弹幕或者直接更改timeline。当插入的弹幕时间上在播放时间之后，那么当播放到那个时间的时候，新的弹幕就会出来。刚刚发出的弹幕可以通过 sendComment （或者在未来 send）方法直接“立即”显示，如果在直播，则可以完全抛弃管理器的时间轴而转来使用 WebSocket通讯+ sendComment实时显示。

实时弹幕因为没有服务器所以不能demo，但是二次开发添加支持的难度并不高，而且我也不想用一个现成的实现束缚使用者。毕竟实时弹幕的实现方法非常丰富，而且各种方法都有优劣。。。

[aptx4869]

@insionng 分段视频估计要在ActionScript里面改api了，不然时间轴都对不上……

[insionng]

@aptx4869 哪里来的ActionScript...videojs播放器是html5类型的哦..现在我找到一个videojs的playlist插件,目前几个视频片段可以连续播放了,的确时间轴对不上,要研究下怎么解决这问题.
@jabbany 感谢这么详细的解说,应该是 https://github.com/jabbany/CommentCoreLibrary/blob/master/docs/CommentCoreLibraryAPI.md 文档里的send 对吧,我今晚再接着研究下,我计划用这个按同时发弹幕到视频弹幕管理器和服务器上的思路来做. 还有还有,那多个视频片段播放的情况下,有没有办法保持弹幕和对应视频片段是同一时间区间的?

[jabbany]

@insionng
那个文档是 1.0.0 的规划，目前还没全实现，send 现在还叫 sendComment，虽然说做的事情差不多。在多段的时候， 弹幕管理器其实是无视具体视频端实现的，time() 函数给入绝对播放时间即可。如果视频有分段，只要在传入的时候传入绝对位置就可以。比如3个10s的分段，如果在第二个分段的第4s，那么 time(14)调用CommentManager就可以顺利连续显示了。

[Catofes]

@jabbany 现在多源渲染是在哪个分支啊？

[Catofes]

我觉得我现在已經看不懂代码了。。。。 src文件夹里好多东西啊

[jabbany]

现在还没写多源渲染呢，但是已经可以支持了。

[jabbany]

状态更新+合并 Issue。以下是目前各个优化方案的优缺点和有待解决的问题。：

• 现 dev-cssonly 采用 CSS transition 动画可实现GPU加速的滚动弹幕。非滚动弹幕依然采取JS手动animate （未来可能考虑keyframe） keyframe 讨论合并到 CSS 优化上 [讨论]关于CSS滚动弹幕 #46。CSS模式依然存在大量加入弹幕会卡的问题。
• Canvas 需要解决测量文字高度，转 靠谱的估算/测量 textWidth与textHeight #26 （相关话题，测量 textHeight） 。另一些问题包括 3D变幻等，不过可以采取联合模式（高级弹幕用DOM）部分解决。复杂的3D什么的WebGL什么的，似乎有一个 Hozuki/Bulletproof 正在搞，打算静观一下

这条先close掉，新的非CSS3/Canvas的优化方法欢迎新开