Skia深入分析9——延迟渲染和显示列表

简介: 概念Android的硬件加速,是先将绘制命令存储起来,然后回放,作为软件绘制的引擎Skia中同样有这样的机制。在Android 4.4的版本中又加入了延迟渲染的Canvas,它相当于默认使用显示列表的Canvas。 先得到显示列表,再进行渲染,便有机会基于绘制API的整体情况做优化调度。比如使用GPU加速,裁剪过度绘制等。从原理上看,很可能在这一层级做比较大的效率提升,

概念

Android的硬件加速,是先将绘制命令存储起来,然后回放,作为软件绘制的引擎Skia中同样有这样的机制。在Android 4.4的版本中又加入了延迟渲染的Canvas,它相当于默认使用显示列表的Canvas。
先得到显示列表,再进行渲染,便有机会基于绘制API的整体情况做优化调度。比如使用GPU加速,裁剪过度绘制等。从原理上看,很可能在这一层级做比较大的效率提升,不过,由于Android既定的渲染框架限制,尽管Google在这方面做的东西很多,生效场景很少,收益也很有限。

显示列表——SkPicture

用法

SkPicture的用法如下:

const int w = 720;
const int h = 1280;
SkPictureRecorder recoder;
SkCanvas* displayCanvas =recoder.beginRecording(w, h, NULL, 0);//这里得到一个专门用来记录的SkCanvas
/*调用SkCanvas的API,但起的是记录命令的作用*/
displayCanvas->drawRect(...);
displayCanvas->drawSprite(...);
displayCanvas->clipRect(...);
displayCanvas->drawText(...);
/*终止绘制API的调用,得到SkPicture*/
SkPicture* picture = recoder.endRecording();

SkBitmap dst;
dst.allocN32Pixels(w, h);
SkCanvas canvas(dst);
c.drawPicture(picture);//用 picture->draw(&canvas)也可以,但最好用前面一种方法
/*此时内容已经在 dst 上面了*/
/*也可以用GPU的方式创建Canvas渲染,怎么用可参考上一篇,*/
picture->unref();//释放 picture

显示列表的记录

记录方案

我们先看一下beginRecording函数:

SkCanvas* SkPictureRecorder::beginRecording(int width, int height,
                                            SkBBHFactory* bbhFactory /* = NULL */,
                                            uint32_t recordFlags /* = 0 */) {
    this->reset();  // terminate any prior recording(s)
    fWidth = width;
    fHeight = height;

    const SkISize size = SkISize::Make(width, height);

    if (NULL != bbhFactory) {
        SkAutoTUnref<SkBBoxHierarchy> tree((*bbhFactory)(width, height));
        SkASSERT(NULL != tree);
        fPictureRecord = SkNEW_ARGS(SkBBoxHierarchyRecord, (size, recordFlags, tree.get()));
    } else {
        fPictureRecord = SkNEW_ARGS(SkPictureRecord, (size, recordFlags));
    }

    fPictureRecord->beginRecording();
    return this->getRecordingCanvas();
}

如上述代码所看到的,主要有两种记录方法,一种是SkBBoxHierarchyRecord,另一种是SkPictureRecord。
SkBBoxHierarchyRecord:以 R-Tree 算法组织绘制任务,这种方式需要计算绘制区域的包围盒,在记录文本绘制命令时这个计算还是相当耗时的,采用R-Tree组织的好处是绘制指定区域时可以快速找出相关的绘制任务。
SkPictureRecord:顺序记录方式,不做处理

任务记录的一些注意点

  1. 图片存储时需要判断该图片是否是可变的(immutable),若不是可变的,需要复制图片到缓存。
  2. SkPaint的Shader及各种特效只存储指针/引用。需要应用自行保证不做更改。
  3. SkPath也是复制了整个SkPath及SkPathRef中所有点到缓存,注意到需要记录和恢复的比较复杂的类,需要实现 writeToMemory 和 readFromMemory 两个方法
  4. 使用SkWriter32写入,在结束记录后将其内容全部复制到 SkPicture

回放过程

Created with Raphaël 2.1.2SkCanvas::drawPictureGPUDeviceEXPERIMENTAL_drawPictureSkPicture::drawSkPicturePlayBack::drawyesno

鉴于GPU绘图时还需要把之前存储在缓存区的bitmap、path等上传为纹理或vbo,直接以纹理/vbo建立缓存机制效率更高,所以有EXPERIMENTAL_drawPicture一条分支,不过目前看来还是实验阶段。
具体如何回放的看src/core/SkPicturePlayBack.cpp中SkPicturePlayBack::draw函数即可,不详述。

延迟渲染——SkDeferredCanvas

Google的注释很清楚地解释了这个类的作用。这个类的用法和原始的SkCanvas基本一致。只是设置了延迟属性后,需要在使用绘图结果前flush一下。

/** \class SkDeferredCanvas
    Subclass of SkCanvas that encapsulates an SkPicture or SkGPipe for deferred
    drawing. The main difference between this class and SkPictureRecord (the
    canvas provided by SkPicture) is that this is a full drop-in replacement
    for SkCanvas, while SkPictureRecord only supports draw operations.
    SkDeferredCanvas will transparently trigger the flushing of deferred
    draw operations when an attempt is made to access the pixel data.
*/

用法如下:

SkSurface* surface =  SkSurface::NewRasterPMColor(720, 1280);
SkDeferredCanvas* canvas = SkDeferredCanvas::Create(surface);
canvas->clear(0x0);
canavs->setDeferredDrawing(true);
/*......*/
canvas->drawRect(...);
canvas->drawText(...);
/*......*/
canvas->flush();//需要这一步来保持绘制完成
canvas->unref();
surface->unref();

另外可以为SkDeferredCanvas设置一个监听器NotificationClient:
class NotificationClient {
public:
virtual ~NotificationClient() {}
virtual void prepareForDraw() {}//准备开始渲染时调用
virtual void storageAllocatedForRecordingChanged(
size_t /newAllocatedStorage/) {}
virtual void flushedDrawCommands() {}//当前绘制任务清空时调用,可以是拿去编码/显示/后处理等
virtual void skippedPendingDrawCommands() {}//当前绘制任务被取消掉时调用,可以用来清除额外的资源
};

相关实践学习
部署Stable Diffusion玩转AI绘画(GPU云服务器)
本实验通过在ECS上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。
目录
相关文章
|
9月前
|
数据可视化 图形学 开发者
【Qt 底层机制之图形渲染引擎】深入理解 Qt 的 渲染机制:从基础渲染到高级图形
【Qt 底层机制之图形渲染引擎】深入理解 Qt 的 渲染机制:从基础渲染到高级图形
1163 4
|
3月前
|
存储 缓存 JavaScript
利用缓存布局信息来减少回流和重绘的发生
【10月更文挑战第24天】通过合理利用缓存布局信息,我们可以在一定程度上降低回流和重绘的发生频率,提高页面的性能和用户体验。这是前端性能优化中的一个重要环节,需要我们在实践中不断探索和总结经验,以找到最适合的解决方案。
|
存储 缓存 JavaScript
如何优化 JavaScript 性能:减少重绘与回流
优化 JavaScript 性能是前端开发中非常重要的课题。在本篇博客文章中,我将重点介绍如何减少重绘(Repaint)与回流(Reflow),以提高 JavaScript 在浏览器中的执行效率。我们将深入探讨导致重绘和回流的原因,并提供一些优化技巧和代码示例来改进性能。
334 0
|
数据采集 缓存 数据可视化
Echarts高级进阶教程:图表渲染大数据量导致卡顿加载时间慢等问题的解决方案
Echarts高级进阶教程:图表渲染大数据量导致卡顿加载时间慢等问题的解决方案
2000 0
|
数据可视化 前端开发 算法
动态渲染拓扑图方案探究
拓扑图是数据可视化领域一种比较常见的展示类型,目前业界常见的可视化展现的方案有ECharts、HighCharts、D3、AntV等。当前的项目使用的是基于ECharts的静态关系图渲染,为了后续可能扩展成动态的拓扑图渲染,本文探索了ECharts的原理以及G6的原理,也算是对自研一个可视化库的基本实现方法做了一个梳理。
301 0
|
前端开发 图形学
Unity中影响UI排序的组件
Unity中影响UI排序的组件
|
存储 运维 并行计算
实时渲染和预渲染有什么区别
实时渲染用于交互式渲染场景,如在3D电脑游戏中,通常每帧必须在几毫秒内渲染。它的意思是计算机在计算屏幕的同时输出和显示屏幕。典型代表是Unreal和Unity。像《黑色神话:悟空》这样的游戏便是使用虚幻引擎4创造出来的。实时绘制的特点是可以实时控制,交互非常方便。
|
存储 缓存 数据处理
并发渲染优化:让文件树的渲染又快又稳
并发渲染优化:让文件树的渲染又快又稳
259 0
并发渲染优化:让文件树的渲染又快又稳
|
Web App开发 JavaScript 前端开发
我优化了进度条,页面性能竟提高了70%
大家好,我是零一。最近我准备在组里进行代码串讲,所以我梳理了下项目之前的业务代码。在梳理的过程中,我看到了有个进度条组件写的非常好,这又想起我刚开始学前端时写的进度条的代码,跟这个比起来真的差距太大了(大部分的初学者应该都想不到,而且我第一次实习的公司带我的mentor亦是如此)。 因此,我想给大家分享一下这个思路极好的进度条组件,同时它也存在非常严重的性能问题,本文末尾也会讲解一下问题所在以及优化方式
306 0
我优化了进度条,页面性能竟提高了70%
|
算法 数据可视化 安全
实时渲染:更优的渲染选择
实时渲染来自游戏世界。最初的目标是尽可能快地,逼真地再现3D场景,以便游戏玩家可以射击怪物并做其他有趣的游戏。在黑暗时代,这需要大量的小技巧和技巧以保持游戏的互动性。随着图形卡速度的提高,场景的真实感自然会好很多
实时渲染:更优的渲染选择