使用Canvas处理滚动弹幕。 #34
使用Canvas处理滚动弹幕。 #34
Conversation
Try to preload scrool comment in divs to avoid large DOM append.
Something to do:
update information when reset and change screen size
still have bug: clear();
Still a little strange. Happen when danmu with veryvery big height.
Conflicts: build/CommentCoreLibrary.js src/CommentCoreLibrary.js
Conflicts: build/CommentCoreLibrary.js src/CommentCoreLibrary.js
Conflicts: build/CommentCoreLibrary.js demo/index.htm src/CommentCoreLibrary.js
|
Surface Pro 不插电源情况下的CPU使用。。。
|
|
在linux系统下i7 2600k 的机子卡崩了…… |
|
2333 这不科学诶 看一下你的canvas硬件加速开了没有？没有的话的确会卡。 chrome打开 chrome：//gpu查看 Firefox 貌似是这里 http://blog.mozilla.org/joe/2010/11/10/how-to-tell-if-youre-using-hardware-acceleration/ On Aug 3, 2014 11:19 AM, "aptx4869" notifications@github.com wrote:
|
|
这个视频同屏弹幕破1800，不卡就见鬼了。。。 我的 i7 2730QM + AMD 6550M 差不多是这个效果。弹幕一多还是一顿一顿的。不过还是能看。 你可以对比一下原CCL demo里面加载那个坑爹的弹幕。印象中我这边直接卡的其他地方就不渲染了～～
|
|
这种高密度弹幕，感觉瓶颈不在CPU，不在GPU，在内存…… |
|
这我还真没注意。我去看看内存。
|
|
我这边内存正常？
还有上图你的潜在占用是340M。。没有理解为什么会有这么高的内存占用。尽管用了buffer，不过buffer也就是同屏最多数量的弹幕个数，少于1800个ctx，不应该有上G的内存占用啊。。 |
|
我重现了你的情况。 大概是这个样子的内存使用率。原因还是因为chrome的canvas的硬件加速是关闭的。chrome://gpu 显示大概如下： 然后你可以试着把硬件加速打开来看看。打开方式是在 chrome://flags 里面勾选 然后 chrome://gpu 应该显示： |
|
好像是这么回事，不过测试页面里的视频502挂掉了，没法验证…… |
|
-23333333 我服务器没有挂啊。。。。好吧啊 等一下吧视频直接挪到github page里面- 我擦咧。 为何我的服务器的NGINX会跪掉了呢。。。。现在应该好了。。 2014-08-07 10:35 GMT+08:00 aptx4869 notifications@github.com:
乔颢 Catofes浅草、洛水、冉枝。 GPG 公钥：http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF1EF10EDE6EA2EC |
|
@aptx4869 现在试试看 应该没问题了 |
|
开了硬件加速试了一下，第一次播放是没这问题了，内存占用少了不少。 |
|
233 我没有发现 等我去重现下试试看。
|
|
我试了试没有重现成功。。。 重放了两次都没有发现有啥问题。不过第三次因为网络原因卡了2333 我想我在写代码的时候有关绘图的部分有一个主canvas 和 一些 buffer . 其中buffer的数目应该小于最大同屏弹幕的数量。对于那个jixian的demo也就是1200条左右。在执行seek的时候这些东西都应该被标记为可以重新利用。所以我没想清楚哪里有泄漏的地方。 你能不能在快崩溃的时候暂停一下，输出一下 window.thevideojs.danmu.cmManager.bctx 的数目。看看数目正常否。谢谢了 |
|
顺便又看了看Chromium调试工具的 Heap Snapshot 然后发现在关闭canvas硬件加速的时候，虽然页面占用了1G多的内存，但是CCL实际占用了7M左右的内存。不知道是我的调试姿势不对，还是这本来就是chromium自身的原因。 你的情况更像是硬件加速跪了切换到了软件加速。我的显存是256M，貌似没有出现类似的问题。你可以试试看win下如何～ 或者升级一下chrome？ 不太理解问题出在哪里。 啊对。显存这玩意javascript控制得了嘛。。。 |
|
btw @jabbany 弹幕类型4和5 （顶部弹幕，底部弹幕）他们之间的层级结构是什么样的啊？ 大概意思是滚动弹幕在最底下一层，然后上面是？ |
|
没有特别的顺序。。。哪个后出现哪个就在上面。。。 |
|
和普通的滚动弹幕之间的关系呢？
|
|
也没有顺序关系。。。理论上后出现的滚动弹幕也可以滚动到在顶部底部弹幕的上方。不知道新版播放器是否改变策略了。 这个behavior主要是为了神弹幕还原，有的曾经会有滚动弹幕遮挡顶部底部的。。。 |
|
赞 这样省事些了
|
|
没法重现就不管它算了，也不知道是浏览器bug还是显卡驱动bug，反正用linux的人太少了，更何况实际中这么高密度的弹幕是根本不可能出现的，除非写服务器端的人有病…… |
|
我也是用linux的啊 ~~ 233 windows下应该没问题，一直用它看新番来着~~ |
|
不过感觉下一个版本要大改动。把每一个弹幕都抽象出来了。 |
|
是的，下一个 modularize 版本将力争推一个大版本号（到1.0.0）并且基本上固定住API接口，把 CCL 的 |
|
围观PR。commit很多很壮观。整合一下？ 我的about:gpu是默认禁用的，我不想强制打开，因为强制打开真的有bug啊。稳定 > 性能。 你的黑边锯齿我猜是没用blendmode。规范的渲染需要alpha blending，如果你打开，我猜测性能马上暴低，因为alpha blending本身比较贵。渲染一致 > 性能。 处理大量弹幕最简单的方法就是不处理。稍微复杂一点就选一些弹幕出来渲染。每个弹幕变成一个canvas内存很快就爆了。 |
|
@nekofs
好久了都忘了自己写的啥了。。。 我这边测试的内存占用貌似不大，不知道这个内存泄露哪里出现的。 至于aboug:gpu强制打开的问题， 我觉得是linux的驱动的问题吧。win下chrome默认是开这一堆东西的。 目前我遇到的电脑大部分都尝试看了看，没啥问题。 360浏览器之类的貌似不行。 黑边锯齿是啥？ |
|
这个pull request 其实可以关的，毕竟 @jabbany 要改构架， 等构架改完之后再吧canvas渲染做成一个模块挂上去好了～ 现在这个更像是一个讨论版了。 |
|
@Catofes 确实可以Close掉。。。不过这里面有很多有意思的讨论，怕Close了就忘了 = =|| |
|
html5这么先进，性能不比Flash高简直说不过去对吧。只是要多测试。 黑边锯齿： |
|
@nekofs HTML5大坑>____>兼容性一塌糊涂。。。 |
搞错分支神马的2333 从新merge蛮麻烦。
这次对于排版直接使用了原来的排版系统，理论上应该和之前样式的没有啥区别。区别估计事在于用Canvas还原弹幕的话，边框略虚，这可能跟Canvas的抗锯齿有关（还TMD关不掉。。）。
效率对比如下：都是Surface Pro with IE，测试的是demo的test6。测试时间40s。
Canvas：
Dom：
感觉Surface终于不发热了～～2333