弹幕场景密集渲染在安卓平台卡顿的问题咨询

[yuerolling]

大佬好，最近基于tgfx去做了一套弹幕，在之前的讨论里沟通了下，之前提到鸿蒙底层线程调度的缺陷，导致小核任务很慢，所以通过提供的API set(TGFX_USE_THREADS OFF),关闭底层多线程，demo基本流畅。最近在做安卓平台的适配，用的surfaceview，发现无论TGFX_USE_THREADS打开与关闭都很卡顿，比鸿蒙上效果差很多，demo进行了安卓适配，测出来也很卡。Tgfx是刚更新的代码，想咨询下大佬是用的不规范，还是说需要额外的能力开发，比如说已经试过

1. 离屏渲染，因为tgfx不支持lock之后做线程切换，就在draw的时候用做了下离屏缓存，效果不明显
2. 硬件渲染，我看tgfx底层已经支持了，所以这个没做改动
3. 双缓冲的方案，现在问题是一帧有时时间很长，因为不支持切线程，所以没法双线程操作，这个无效果

目前用了华为P10 一加ACE2 PRO测过 都不行 很卡 ，surfaceview 应该比提供的demo里TextureView效果要好 ，但也卡帧，下面是测试的demo ,tgfx 版本是6月11号的
android.zip

[domchen]

你稍等一下，下周应该文字图集相关的功能就上线了，到时候更新一下最新代码再测试一下，文本渲染相关性能应该会有大幅的提升。如果还有问题在那个基础上我们再继续排查。

[domchen]

@yuerolling Android上我们关闭了EGL的VSYNC阻塞，帧回调是靠你上层的视图来触发的。你用ValueAnimator的帧刷新回调了麽？用那个就是天然和vsync同步的。如果已经是ValueAnimator回调的，你也可以试下删掉这行代码编译测试下平滑度是否有变化：https://github.com/Tencent/tgfx/blob/main/src/gpu/opengl/egl/EGLDevice.cpp#L158

[yuerolling]

@domchen 我用的Choreographer.getInstance().postFrameCallback(this)这个回调，大佬 android的也关了么，我记得当时是鸿蒙关了 ，现在鸿蒙反而比较流畅
刚试了下 无论ValueAnimator 还是Choreographer.getInstance().postFrameCallback(this) ，无论(https://github.com/Tencent/tgfx/blob/main/src/gpu/opengl/egl/EGLDevice.cpp#L158) 这个删不删，都会看到抖动的效果，我用小米14测了 ，也有 ，但是效果没有一加的明显，

[domchen]

那和vsync就没关系，demo确保能还原的话 @richardshan0614 也看一下导致drawRect都不平滑的问题原因是什么

[yuerolling]

@domchen @richardshan0614 我试了下 把测试demo从TextureView 换成surfaceView 基本动画流畅了，之前动画不流畅可能还是和android这两个组件的机制有关，这边没有好的建议的话，我建议大佬如果有继续优化文字的计划，还是按照大佬的计划来，现在文字虽然比最开始有很大提升，但是跟系统的 还是有差距。
还有个问题，我之前提到的方式二(缓存image)的效果表现不如方式一（直接drawapi），这个希望分析下，是否合理，按照之前沟通的 好像结论是反的。

[yuerolling]

android.zip

@richardshan0614 这是我surfaceview的demo，昨天textureview不流畅的问题可以暂时不用管了
TextureView: GPU → SurfaceTexture → View渲染树合成 → SurfaceFlinger → 显示
SurfaceView: GPU → Surface → 直接SurfaceFlinger → 显示
Textureview因此会有渲染延迟而且每帧的延迟不稳定，而弹幕属于规则小尺寸快速的移动的，所以对延迟要求比较高（1~2ms），不稳定不可预期的延迟会产生视觉抖动

现在Surfaceview 我测下来（一加手机）
方式一 （直接draw）： 25条文本，大约 12ms
方式二 （缓存image）: 25条文本，大约6ms
现在有两个问题

1. 方式二，会有抖动 ， @domchen 我注释掉(https://github.com/Tencent/tgfx/blob/main/src/gpu/opengl/egl/EGLDevice.cpp#L158)这句话就很流畅了，大佬看看，要不要提供个宏或者条件语句（目前还不清楚是不是和机型有关）。
2. 这部手机 还是会出现下图这种

可能是跟字体有关(小米手机也出现了)，不过大佬 这种情况有没有异常检测和处理机制，而且在从60hz到120hz的动态变化的时候特别容易出现这种情况（运行的时候，用手点击屏幕）

上面两个问题能解决的话，基本能覆盖我的场景了

@richardshan0614 大佬 顺便咨询下 ，后续 tgfx对文字相关的渲染的还有优化需求是吧，有个case我没测试顺便咨询下，draw 一个字10次，和一次draw10个字，底层成本区别大么

[domchen]

@yuerolling 在原帖下回复太长了都折叠了不方便阅读，我们都开新的回复吧。关于Android TextureView帧率不稳定会抖动的问题可以参考这个文章：https://zhuanlan.zhihu.com/p/147322501 核心应该是因为你开启了异步渲染，然后有的帧渲染太快了，反而可能一帧上屏了两次导致有一帧没显示出来。这个确实是Android系统的设计问题。可以参考下这篇文章的分析过程看看有没有绕过的方法。

1.你把EGLDevice里的VSYNC禁用的代码注释掉就流畅了是麽？那要确认一下你上层的帧刷新回调是从哪来的？用了ValueAnimator吗？理论上用了那个应该就已经是和VSYNC同步的了。如果你已经用了ValueAnimator，还是出现不流畅的问题。能否帮忙录制两个对比视频我们确认一下，就是EGLDevice上注释掉那句话和不注释分别跑一下。如果确认是这个表现。那可能Android上还是要强制开VSYNC的我们就移除这行代码。

2.这个Bug @richardshan0614 还在排查中，是BUG我们都会解决掉的。

文字相关的我们还会持续优化，你提的场景一次draw 10个文字肯定是快于分别draw的。但是理论上差距没有特别明显。因为我们这块和Skia的机制不一样，Skia的每次draw都会创建实际的Op，然后再判断能否合并，合并之后再销毁Op。这样就平白多了特别多的计算。我们内部的处理是先加到pending列表，无法继续合并之后最终才创建一个Op，没有任何冗余的计算。但建议是能合并的尽量合并，多次draw额外的开销主要是各种bounds检查。批量计算一次bounds然后判断是否相交会稍微少点计算量。

[yuerolling]

@domchen 好的大佬 ，本身用TextureView 或者SurfaceView这个异步渲染肯定是要的，我一会去研究下你推荐的那个方案

关于流畅的问题，我参考你的建议以及我之前的回调分别用下面两种方式 Choreographer.getInstance().postFrameCallback 和ValueAnimator，核心代码如下：
// 🔧 Choreographer回调
private val frameCallback = object : Choreographer.FrameCallback {
override fun doFrame(frameTimeNanos: Long) {
if (isRenderingActive && holder.surface != null && holder.surface.isValid) {
val frameTimeMillis = frameTimeNanos / 1_000_000L
nativeRender(frameTimeMillis)
Choreographer.getInstance().postFrameCallback(this)
}
}
}

// 🔧 ValueAnimator回调
private val valueAnimatorCallback = ValueAnimator.AnimatorUpdateListener {
    if (isRenderingActive && holder.surface != null && holder.surface.isValid) {
        val frameTimeMillis = System.nanoTime() / 1_000_000L
        nativeRender(frameTimeMillis)
    }
}

我结合资料简单跟了下valueAnimator 的源码，其实它底层也是通过AnimationHandler调用的 Choreographer.getInstance().postFrameCallback能力，不过可能做了插帧，补帧操作，我测试了三种方案

1. valueAnimator +VSYNC禁用（默认推荐的方案）
2. valueAnimator +VSYNC启用
3. Choreographer.getInstance().postFrameCallback +vsync 启用
   先说下结论，
   方案三效果最好 最流畅
   方案二 效果也基本流畅，但是碰到从60hz到120hz变化的情况，跳动比较明显
   方案一 回时不时出现卡顿的视觉效果，而且跟渲染的数量无关，规律也比较随机

下面是我分别对应的方案1,2,3的视频，考虑网络的问题，我这里基本各自切了10秒左右，大佬可以下下来，用播放器看看，网页看的话，可能网页回裁帧，都比较卡，另外这里视频只是参考，其中视频一种的卡顿因为卡的比较随机，卡的频率也未知，所以实际效果可能更差

方式1.zip
方式2.zip
方式3.zip

[richardshan0614]

@yuerolling 1.现在默认已经启用了vsync。 2.字形错乱问题，我在小米 13 确实容易复现，在小米 12 上没有复现问题。我还在排查，问题修复后会及时同步。

[yuerolling]

@richardshan0614 如果有一加手机的话 可以试试 一加，我在一加上很容易复现，特别是开启缓存image的方案 更容易出现

[richardshan0614]

@yuerolling .字形错乱问题已经解决 更新代码试试

[yuerolling]

@richardshan0614 我pull 的今天的代码 试了几次 确实ok 了，现在字基本OK了，等大佬有较大的性能提示 我再进一步 测试，关于字体路径的问题 ，有什么好的 参考意见么,就是如下的代码

static const std::string FallbackFontFileNames[] = {"/system/fonts/NotoSansCJK-Regular.ttc",
"/system/fonts/NotoSansSC-Regular.otf",
"/system/fonts/DroidSansFallback.ttf"};
for (auto& fileName : FallbackFontFileNames) {
auto typeface = tgfx::Typeface::MakeFromPath(fileName);
if (typeface != nullptr) {
host->addTypeface("default", std::move(typeface));
break;
}
}
auto typeface = tgfx::Typeface::MakeFromPath("/system/fonts/NotoColorEmoji.ttf");
if (typeface != nullptr) {
host->addTypeface("emoji", std::move(typeface));
}
还是说 我去参考libpag里的方式去处理

[richardshan0614]

1.libpag 从系统 fonts.xml 读取字体来注册，更严谨一些，可以参考。 2. 另外如果要使自定义的字体，也可以将font文件存储到sdcard 并且给予 app 相应的读取权限。这里比较灵活，多种方法都可以。

[yuerolling]

@domchen @richardshan0614 现在文字基本满足需求 ，近期可能考虑 上线文字渲染相关的，不知道能否提供一个tag版本

[domchen]

我们预计下周可以发个2.1的版本