Chromium代码:实现GPU->GPU的直接图片传递,不需要通过CPU进行中转

优化GPU视频到2D画布复制流程,提升性能与电池寿命
此提交优化了在渲染加速2D画布上绘制GPU解码视频的流程,通过引入缓存机制,使得GPU到GPU的直接复制成为可能,从而显著提高了速度并节省了电池电量。此外,该更改还修复了Android平台上的视频背景显示问题,并确保了跨平台的黑色背景绘制效果。实现了对视频帧纹理的直接复制至GPU纹理,减少了中间内存复制步骤,进一步提升了整体效率。

commit0c4e9d8781aea6e52fdb4a7aee978817910c67ea
authordongseong.hwang Thu Jan 08 20:11:13 2015
committerCommit bot Thu Jan 08 20:12:02 2015

media: Optimize HW Video to 2D Canvas copy.

Currently, when we draws GPU decoded Video on accelerated 2D Canvas, chromium
reads back pixel from GPU and then uploads the pixel to GPU to make a SkBitmap.
It's so inefficient for both speed and battery. On the other hand, only Android
copies GPU-GPU in this case, but Android doesn't have cache mechanism which
SkCanvasVideoRenderer provides.

This CL makes all platforms copy gpu-gpu with cache mechanism. Cache mechanism
is useful when 2d canvas draws a video frame many times.
e.g. http://craftymind.com/factory/html5video/CanvasVideo.html

In addition, fix white video background on Android when not loaded. Other platforms
draw black background thanks to SkCanvasVideoRenderer::Paint().

In detail of the changes;
1. Implement gpu-gpu copy in SkCanvasVideoRenderer::Paint() like previous
WebMediaPlayerAndroid::paint().
2. Move duplicated GPU code on WebMediaPlayerImpl and WebMediaPlayerAndroid to
SkCanvasVideoRenderer.

Perf data on i5 IvyBridge
blink_perf.all:Canvas_draw-video-to-hw-accelerated-canvas-2d
15.8x speed up: 116.27 runs/s -> 1847.23 runs/s
NOTE: measure after disabling cache in SkCanvasVideoRenderer

BUG=401058, 263667

Review URL: https://codereview.chromium.org/445013002

Cr-Commit-Position: refs/heads/master@{#310577}

从视频复制到图片,GPU到GPU直接传递,不需要经过CPU内存?

// static
void SkCanvasVideoRenderer::CopyVideoFrameTextureToGLTexture(
    gpu::gles2::GLES2Interface* gl,
    VideoFrame* video_frame,
    unsigned int texture,
    unsigned int level,
    unsigned int internal_format,
    unsigned int type,
    bool premultiply_alpha,
    bool flip_y) {
  DCHECK(video_frame && video_frame->format() == VideoFrame::NATIVE_TEXTURE);
  const gpu::MailboxHolder* mailbox_holder = video_frame->mailbox_holder();
  DCHECK(mailbox_holder->texture_target == GL_TEXTURE_2D ||
         mailbox_holder->texture_target == GL_TEXTURE_EXTERNAL_OES);
  gl->WaitSyncPointCHROMIUM(mailbox_holder->sync_point);
  uint32 source_texture = gl->CreateAndConsumeTextureCHROMIUM(
      mailbox_holder->texture_target, mailbox_holder->mailbox.name);
  // The video is stored in a unmultiplied format, so premultiply
  // if necessary.
  gl->PixelStorei(GL_UNPACK_PREMULTIPLY_ALPHA_CHROMIUM, premultiply_alpha);
  // Application itself needs to take care of setting the right |flip_y|
  // value down to get the expected result.
  // "flip_y == true" means to reverse the video orientation while
  // "flip_y == false" means to keep the intrinsic orientation.
  gl->PixelStorei(GL_UNPACK_FLIP_Y_CHROMIUM, flip_y);
  gl->CopyTextureCHROMIUM(GL_TEXTURE_2D, source_texture, texture, level,
                          internal_format, type);
  gl->PixelStorei(GL_UNPACK_FLIP_Y_CHROMIUM, false);
  gl->PixelStorei(GL_UNPACK_PREMULTIPLY_ALPHA_CHROMIUM, false);
  gl->DeleteTextures(1, &source_texture);
  gl->Flush();
  SyncPointClientImpl client(gl);
  video_frame->UpdateReleaseSyncPoint(&client);
}

主要实现代码在这里,主要缺点是:从代码可以看出,仍然需要GPU内部到GPU的内存复制,做不到Zero-Copy(要是能够做到GPU内存指针的swap,或C++11里的move构造,就更好了)。但是显然比GPU-->CPU-->GPU这种中转效率上要好一点

理论上来讲,可以实现GPU硬件加速的WebView到View的GPU snapshot快照截图的直接传递。
<think>好的,我现在需要处理用户关于--disable-gpu--disable-chromium-sandbox这两个命令行参数的询问。首先,我得回忆这两个参数的作用,并确保信息准确。 用户可能是在运行基于Chromium的应用程序时遇到了问题,比如Electron应用或Chrome浏览器本身。我需要先分别解释每个参数的意义和用途。 对于--disable-gpu,我记得这是用来禁用GPU硬加速的。可能在某些情况下,用户的显卡驱动兼容,导致应用崩溃或图形渲染问题。这时候禁用GPU可以作为一种排查手段。需要说明它适用于解决图形相关的问题,但长期使用可能会影响性能。 然后是--disable-chromium-sandbox,这个参数涉及沙箱安全机制。沙箱的作用是限制进程权限,防止恶意代码对系统造成破坏。禁用沙箱可能会带来安全风险,所以通常只在特定情况下使用,比如在Linux上权限足时,或者调试需要。需要强调用户应谨慎使用,并仅在必要时临时启用。 接下来,我需要考虑用户可能的场景。比如,用户可能在开发Electron应用时遇到崩溃,或者在使用Puppeteer进行自动化测试时出现问题。这时候他们可能需要这些参数来绕过问题。但需要提醒他们这些只是临时解决方案,长期应修复根本原因。 另外,要确保回答结构清晰,分点说明每个参数的作用、适用场景和注意事项。同时,语言要口语化,避免技术术语过多,让用户容易理解。 最后,需要检查是否有遗漏的信息或可能的误解。比如,是否混淆了Chromium沙箱和其他类型的沙箱?是否需要提到具体的使用方法,比如在命令行中如何添加这些参数?可能需要补充示例,比如在启动Chrome时加上这些参数,或者如何在Electron应用中配置。 总之,回答要准确、实用,并强调安全性和正确使用场景,帮助用户解决问题同时避免潜在风险。</think>以下是对`--disable-gpu`和`--disable-chromium-sandbox`命令行参数的详细说明: --- ### 1. `--disable-gpu` **作用** 禁用应用程序的GPU硬件加速功能,强制使用软件渲染。 **适用场景** - 当应用程序(如基于Chromium的浏览器、Electron应用)因显卡驱动兼容导致崩溃或显示异常时 - 在虚拟化环境或旧硬件中运行出现图形渲染问题 - 调试图形相关的崩溃问题时 **注意事项** $$性能影响 = \text{可能显著降低渲染速度}$$ 长期使用可能导致页面卡顿,建议仅作为临时解决方案。 --- ### 2. `--disable-chromium-sandbox` **作用** 关闭Chromium的沙箱安全机制,允许进程以更高权限运行。 **适用场景** - 在Linux系统上因权限配置问题导致应用无法启动时 - 调试需要绕过沙箱限制的特殊场景 - 某些Docker/容器环境中运行Chromium时 **注意事项** $$安全风险 \propto \frac{1}{\text{沙箱防护强度}}$$ 禁用后会显著降低安全性,可能被恶意代码利用,**生产环境绝对禁止使用**。 --- ### 典型使用案例 ```bash # Electron应用启动示例 electron --disable-gpu --disable-chromium-sandbox # Headless Chrome测试示例 chrome --headless --disable-gpu --no-sandbox ``` --- ### 关联知识补充 - **沙箱机制**:通过隔离进程权限实现纵深防御,Chromium每个标签页默认运行在独立沙箱中 - **GPU加速**:利用显卡处理CSS动画、WebGL等任务,可提升性能约$3\times$ - **替代方案**:更新显卡驱动、配置正确沙箱权限(推荐)比直接禁用更安全有效 建议优先通过`chrome://gpu`诊断GPU问题,或使用`--use-angle`选择渲染后端。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值