请教下作者关于使用的问题 #520
-
|
你好，我正在用tgfx 在鸿蒙上构造一套弹幕的场景，单个item第一次 通过tgfx::Surface::Make(grContext, width, height, false) （目前测试场景所有的item的surface复用一个），获取的canvas，生成Image,后面进行Image的平移，测试后（测试case:1秒10条,每条10个字符左右），发现每帧的提交上屏context->flushAndSubmit(); |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 42 replies
-
|
tgfx 是main 分支 2月17号之前的版本，目前跟踪了下 entry/src/main/cpp/third_party/tgfx/src/gpu/tasks/TextureUploadTask.cpp#onMakeResource# decoder->decode() 这一句比较耗时 |
Beta Was this translation helpful? Give feedback.
-
|
构造一下最小的可以运行的demo上传吧，这样信息有限看不出来用法具体有什么问题。 |
Beta Was this translation helpful? Give feedback.
-
|
另外请更新一下main分支，我们只基于最新代码看问题，这样可以排除是已经解决过的问题。 |
Beta Was this translation helpful? Give feedback.
-
|
napi_init.zip |
Beta Was this translation helpful? Give feedback.
-
|
auto start = std::chrono::high_resolution_clock::now(); // 记录开始时间 记录的这一段的耗时 ，然后打印出的结果 截取部分如下 |
Beta Was this translation helpful? Give feedback.
-
|
这里只是举例 实际使用的时候 每一条的样式很复杂 ，然后长度还不一样 不知道tgfx有没有什么官方建议 |
Beta Was this translation helpful? Give feedback.
-
|
你这个主要是自身业务逻辑问题。你的判断条件是移动一整批弹幕出屏幕，然后就集中在一次渲染帧里生成了10个新的弹幕的截图缓存，这一帧的压力当然就非常大。其他帧就只是常规移动然后绘制这些缓存的截图，那些开销极低基本可以忽略。正常的弹幕逻辑应该也不是你这样的情况，可以分散点创建，比如每帧新增一个弹幕缓存，然后移动。或者移出一个到屏幕外后，就再补充创建另一个。不要扎堆创建就好了。另外有一个是跟用法有关系的问题，生成截图缓存的地方，不要去复用同一个Surface，这个毫无复用必要，因为你创建的Surface是要生成截图的，如果复用了会导致下次调用Surface的绘制是产生一次像素拷贝，性能就更低了。这种创建截图缓存的场合，每次使用独立的新的Surface就行。 |
Beta Was this translation helpful? Give feedback.
-
|
大佬，有消息记得及时通知下 |
Beta Was this translation helpful? Give feedback.
-
|
有相关的同学在跟进，这两天都在调试，已经定位了是 Freetype 的耗时异常，你的业务代码写法没问题，内部的这个性能表现比较不符合预期。我们看看怎么解决。修复后更新就行。 |
Beta Was this translation helpful? Give feedback.
-
|
好的 |
Beta Was this translation helpful? Give feedback.
-
|
我们定位出问题原因了，是鸿蒙设备上开启了多线程后，子线程可能强制被运行在了效能核心上，相同的任务比主线程慢10倍。我们已经和华为反馈了这个问题，看看他们那边怎么解决。等解决之后会再提交最终的修复，目前暂时可以通过屏蔽多线程渲染的方法规避这个问题。更新main分支最新代码会有一个禁用多线程的编译开关：TGFX_USE_THREADS，编译的时候传递参数：-DTGFX_USE_THREADS=OFF 就行。 |
Beta Was this translation helpful? Give feedback.
-
|
刚试了下 ，所以现在或者说以后也应该采用整行绘制的方式，不需要逐个字去绘制，目前整行绘制的方式，看数据基本ok |
Beta Was this translation helpful? Give feedback.
-
|
大佬，还有个问题，emoji 和非emoji 混排的，这边建议我用harfbuzz 去处理，还是说tgfx内部有提供可用的方案 |
Beta Was this translation helpful? Give feedback.
-
整行绘制就行，等鸿蒙的问题修复好再打开多线程性能会进一步提升。 |
Beta Was this translation helpful? Give feedback.
-
如果你不要求识别双字符连接的emoji就用不到harfbuzz，参考我们在core包上层构造的layers模块就行，里面有个TextLayer，你可以参考里面的实现做基本排版，或者直接用这个layers模块，测试用例里有用法的参考 |
Beta Was this translation helpful? Give feedback.
我们定位出问题原因了，是鸿蒙设备上开启了多线程后，子线程可能强制被运行在了效能核心上，相同的任务比主线程慢10倍。我们已经和华为反馈了这个问题，看看他们那边怎么解决。等解决之后会再提交最终的修复，目前暂时可以通过屏蔽多线程渲染的方法规避这个问题。更新main分支最新代码会有一个禁用多线程的编译开关：TGFX_USE_THREADS，编译的时候传递参数：-DTGFX_USE_THREADS=OFF 就行。