问题标签 [surfaceflinger]

我想通过 android 应用程序使用背景更改像素颜色。这意味着整个屏幕，而不是图像文件。

如何修改像素颜色？

搜索结果，我可以找到“Bitmap”、“Surfaceflinger”、“Framebuffer”。

但是，我不知道什么是正确的方法。

我正在尝试在云中设置一些 android 自动化（具体为 Docker）。

这是我的码头文件：

我使用以下命令创建 avd：

使用以下命令运行模拟器：

使用此设置我无法运行 avd 得到错误：

我想在特定 android 智能手机的部分屏幕上放置一个硬件键盘（就像 Galaxy S7 edge 键盘盖一样）。所以我需要android系统始终只使用未被键盘占用的屏幕部分，即使在全屏视频播放等时也是如此。但是服务需要能够处理被键盘占用的区域的触摸事件键盘。这不需要在启动时工作。

解决方案可能使用股票 android（具有 root 访问权限）或修改后的 LineageOS。

我倾向于认为股票 android 没有解决方案。

但是Android开源项目太复杂了，我找不到地方开始修改。窗口管理器服务、surfaceflinger 还是其他？

我的意图是修改 surfaceflinger 将是最通用的解决方案。是否可以修改 surfaceflinger，或者它是否与 HAL 和部分二进制 blob 静态链接？我希望surfaceflinger 不会以任何方式处理触摸事件，对吧？

一个不接触surfaceflinger的模糊想法是修改窗口管理器以要求surfaceflinger创建一个尺寸更小的虚拟显示器作为原生显示器，将其用于任何东西而不是原生显示器，并将其blit到原生显示器。

另一个想法是在窗口管理器中修改窗口的矩形。但我不知道这是否可能（特别是对于全屏视频播放）。

触摸事件也需要修改。顺便问一下，窗口管理器是否路由触摸事件？

是否有任何使用surfaceflinger的android组件直接绕过窗口管理器和我可能的修改？例如，应用程序可能会向 Surfaceflinger 询问屏幕尺寸/分辨率，还是由窗口管理器发送此信息？

有没有更简单的方法？

有什么提示吗？

DispSync之类的源码我都看过，但是太复杂了。

我了解到的是“FrameCallback”是由 APP_VSYNC 事件触发的，它可能与 HW_VSYNC 有时间偏移。那么，我怎么知道 HW_VSYNC 的准确时间呢？

如果 FrameCallback 的时间参数告诉 APP_VSYNC 时间，我在哪里可以得到 HW_VSYNC 和 APP_VSYNC 之间的偏移值，以便我可以计算硬件 vsync 时间？

我一直在阅读这个 URL 以了解表面抛掷物。

https://source.android.com/devices/graphics/arch-sf-hwc

其中，下面的块我无法理解。如果有人用一个例子来解释，那就太好了。

当屏幕上没有任何变化时，叠加平面的效率可能低于 GL 合成。当覆盖内容具有透明像素并且重叠图层混合在一起时尤其如此。在这种情况下，HWC 可以选择为部分或所有层请求 GLES 合成并保留合成缓冲区。如果 SurfaceFlinger 返回要求合成同一组缓冲区，HWC 可以继续显示先前合成的暂存缓冲区。这可以提高空闲设备的电池寿命。

我正在调查我的 Android 应用程序中的丢帧现象。它们是不规则的，平均大约每秒发生一次。我已将相关渲染器与一个非常简单的着色器配对，并且我确信帧渲染时间很短。

当我运行 systrace 时，我可以看到丢帧的样子，但原因似乎是 HW_VSYNC_0 信号偶尔无法翻转（即它在半个周期内保持在 0 或 1）。我的理解（来自这个答案）是这个时钟来自显示硬件，因此应该是常规的。

VSYNC-sf 信号无论如何都会继续进行，尽管它偶尔也会翻转，大概是为了恢复同步而拼命尝试。

我的问题：这是预期的行为，是什么导致它发生？

我正在研究 Jetson TK1 板。我已经修改了 screencap 应用程序的代码，以在 while 循环中读取屏幕内容并将数据保存为图像。为此，我使用 ScreenshotClient 类中的 update() 方法。在运行了 100 次 while 循环后，我注意到我的进程的堆大小不断增加。我确实在每次 update() 调用之前调用了 release() 方法。我的代码如下所示。

我不确定这可能是什么原因。任何帮助将不胜感激。

谢谢你。

当解码的输出缓冲区可用并且您希望将其渲染到屏幕上时。使用 MediaCodec NDK API，如果您已经注册了要渲染的本机窗口，则可以选择调用 AMediaCodec_releaseOutputBufferAtTime()。

我的问题是，一旦您调用 AMediaCodec_releaseOutputBufferAtTime() 直到帧显示在屏幕上，代码流是什么。我对流量知之甚少。就像这里提到的函数一样，使用时间戳调用 queueBuffer() 并在 Native Window 上对缓冲区进行排队。然后在下一个 VSYNC 事件上获取它，并在下一个下一个 VSYNC 事件上显示。我的理解对吗？

另外，我想知道一旦在 ANativeWindow 上调用 queueBuffer() 直到帧显示到屏幕上会发生什么。

我正在尝试在尽可能多的 Android 设备上以 60 fps 的速度运行具有挑战性且对延迟敏感的应用程序。它涉及处理来自相机的实时帧（理想情况下也是 60 fps）以及使用 OpenGL ES 2/3 在顶部渲染额外的图形。

我首先只是尝试识别和最小化活动的任何系统级开销，使用带有最小测试应用程序的 systrace，该应用程序在 SurfaceTexture 中获取相机帧并使用 OpenGL ES 2 将它们渲染到 GLSurfaceView。

我一直在研究带有 Android 8.0 的三星 Galaxy S8（具有 Mali GPU 和 4 大 4 小 CPU 设置的 Exynos 版本）。

当接收到相机帧但不渲染它们时（例如，通过将 GLSurfaceView 切换到 RENDERMODE_WHEN_DIRTY 而不是 RENDERMODE_CONTINUOUSLY），CPU 使用率在整个板上显得相当低，每帧的 CPU 使用量很少，这看起来与 SurfaceTexture 的队列和出队缓冲区有关。正如预期的那样，当没有更新任何表面时，SurfaceFlinger 似乎什么都不做。

一旦我开始渲染新帧，事情就会变得更加有趣。我的应用程序中的 GLThread 只需要大约 1.5 毫秒的 CPU 时间，这与我的预期大致相同。出乎意料的是 SurfaceFlinger 所需的 CPU 时间。

这是 systrace 的一些输出，对于大多数帧来说都是典型的：

呈现的每一帧都经过 2 个 SurfaceFlinger 操作 - 有一个handleMessageInvalidate调用 an updateTexImage，然后是一个handleMessageRefresh主要用于 的doComposition，其中大部分用于postFramebuffer.

请注意，此时的大部分时间，线程在 CPU 上处于活动状态，而不是处于休眠状态。这大约是 SurfaceFlinger 中一个核心花费的帧时间的三分之一——如果调度程序决定为我的一个重要线程使用同一个核心，这将非常重要。

我已经阅读了很多关于 SurfaceFlinger 内部的内部文档，包括讨论硬件 Composer 的页面：https ://source.android.com/devices/graphics/arch-sf-hwc 。

我对 HWC 的理解是所有的合成都是在显示硬件中完成的——我希望 CPU 端的工作尽可能少；只是锁定最新的缓冲区并将它们传递给 HWC。

dumpsys SurfaceFlinger确实表明 HWC 正在用于所有层：

发生什么了？为什么这里的 HWC 这么贵？我应该为应用程序使用更好的（更低的开销）模式吗？

我希望 NEON CPU 合成器能够在 5 毫秒左右的时间内通过这些层，因此 HWC 在 CPU 使用率方面并没有带来多大的优势。

在 Android 8 及更高版本中，有两个处理图形的功能。SurfaceFlinger 使用 GLES 对某些层进行渲染，并将其他层传递给 Hardware composer 处理。我的问题是，有没有办法让系统只使用 GLES 来渲染一切所以我可以使用着色器（GLSL）代码来正确操作帧缓冲区。

项目文件到处都有 HWC 文件。我试图找到一种方法来改变每一帧。