精华内容
下载资源
问答
  • Vue渲染过程浅析

    2020-10-17 07:33:43
    主要介绍了Vue渲染过程浅析,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  • 个人理解url渲染过程

    2021-08-09 17:54:17
    个人理解url渲染过程
  • webkit渲染过程

    千次阅读 2015-03-16 19:52:50
    webkit一般性渲染过程    在浏览器中,有一个最重要的模块,它主要作用是将页面转变成可视化的图形结果,这就是浏览器内核。通常,它也被称为渲染引擎。所谓的渲染,就是根据描述或者定义构建数学模型...

           webkit一般性渲染过程

          


           在浏览器中,有一个最重要的模块,它主要作用是将页面转变成可视化的图形结果,这就是浏览器内核。通常,它也被称为渲染引擎。所谓的渲染,就是根据描述或者定义构建数学模型,通过模型生成图像的过程。浏览器的渲染引擎就是能够将HTML/CSS/JavaScript文本及其相应的资源文件转换成图像结果的模块。
         根据渲染引擎所提供的渲染网页的功能,一般而言,它需要包含很多模块,主要分三层,最上层用虚线框住的是渲染引擎所提供的功能。


     
          从图中大致可以看出,一个渲染引擎主要包括HTML解释器、CSS解释器、布局和JavaScript引擎等,其他还有绘图模块、网络等并没有在图中直接表示出来。
    •       HTML解释器:解释HTML文本的解释器,主要作用是将HTML文本解释成DOM树,DOM是一种文档的表示方法。
    •       CSS解释器:级联样式表的解释器,它的作用是为DOM中的各个元素对象计算出样式信息,从而为计算最后网页的布局提供基础设施。
    •       布局:在DOM创建之后,Webkit需要将其中的元素对象同样式信息结合起来,计算它们的大小位置等布局信息,形成一个能够表示这所有信息的内部表示模型。
    •       JavaScript引擎:使用JavaScript代码可以修改网页的内容,也能修改CSS的信息,JavaScript引擎能够解释JavaScript代码并通过DOM接口和CSSOM接口来修改网页内容和样式信息,从而改变渲染的结果。
          这些模块依赖很多其他的基础模块,这其中包括网络、存储、2D/3D图形、音频视频和图片解码器等。实际上,渲染引擎中还应该包括如何使用这些依赖模块的部分。
         一般的渲染过程:如下图,从左上角开始,首先是网页内容,输入到HTML解释器,HTML解释器在解释它后构建成一棵DOM树,这期间如果遇到JavaScript代码则交给JavaScript引擎去处理;如果网页中包含CSS,则交给CSS解释器去解释。当DOM建立的时候,渲染引擎接收来自CSS解释器的样式信息,构建一个新的内部绘图模型。该模型由布局模块计算模型内部各个元素的位置和大小信息,最后由绘图模块完成从该模型到图像的绘制。


     
          图中虚线表示在渲染过程中,每个阶段可能使用到的其他模块。在网页内容的下载中,需要使用到网络和存储,这点显而易见。但计算布局和绘图的时候,需要使用2D/3D的图形模块,同时因为要生成最后的可视化结果,这时需要开始解码音频、视频和图片,同其他内容一起绘制到最后的图像中。
          在渲染完成之后,用户可能需要跟渲染的结果进行交互,或者网页自身有动画操作,一般而言,这需要持续的重复渲染过程。
     
    Webkit的加载和渲染
     
            浏览器的主要作用就是将用户输入的URL转变成可视化的图像。按照某些文档的分析,这其中包含两个过程,其一是网页加载过程,就是从URL到构建DOM树;其二是网页渲染过程,从DOM树到生成可视化图像。其实,这两个过程也会交叉,很难给予明确的区分,所以,为了简单起见,统称网页渲染过程。
        网页渲染还有一个特性,就是网页通常比我们的屏幕可视面积要大,而当前可见的区域,我们称为视图(viewport)。因为网页比可视区域大,所以浏览器在渲染网页的时候,一般会加入滚动条以帮助翻滚网页。就用户体验来说,垂直方向滚动效果好于水平方向。
     
            Webkit的渲染过程
         整个渲染的过程中的包含数据和模块是:数据包含网页内容、DOM、内部表示和图像,模块则包括HTML解释器、CSS解释器、JavaScript引擎以及布局和绘图模块。
        根据数据的流向,这里将渲染过程分成三个阶段,第一个阶段是从网页的URL到构建完DOM树,第二个阶段是从DOM树到构建完WebKit的绘图上下文,第三个阶段是从绘图上下文到生成最终的图像。


     
          图中描述的是从网页URL到构建完DOM树的这个过程,数字表示的是基本顺序,当然也不是严格一致,因为这个过程可能重复并且可能交叉。
        具体的过程如下。
        1.当用户输入网页URL的时候,WebKit调用其资源加载器加载该URL对应的网页。
        2.加载器依赖网络模块建立连接,发送请求并接收答复。
        3.WebKit接收到各种网页或者资源的数据,其中某些资源可能是同步或异步获取的。
        4.网页被交给HTML解释器转变成一系列的词语(Token)。
        5.解释器根据词语构建节点(Node),形成DOM树。
        6.如果节点是JavaScript代码的话,调用JavaScript引擎解释并执行。
        7.JavaScript代码可能会修改DOM树的结构
        8.如果节点需要依赖其他资源,例如图片、CSS、视频等,调用资源加载器来加载它们,但是它们是异步的,不会阻碍当前DOM树的继续创建;如果是JavaScript资源URL(没有标记异步方式),则需要停止当前DOM树的创建,直到JavaScript的资源加载并被JavaScript引擎执行后才继续DOM树的创建。
     
        在上述的过程中,网页在加载和渲染过程中会发出“DOMContent”事件和DOM的"onload"事件,分别在DOM树构建完成之后,以及DOM树建完并且网页所依赖的资源都加载完成之后发生,因为某些资源的加载并不会阻碍DOM树的创建,所以这两个事件多数时候不是同时发生的。
        接下来就是WebKit利用CSS和DOM树构建RenderObject树直到绘图上下文
        

     
        这一阶段的具体过程如下:
        1.css文件被css解释器解释成内部表示结构
        2.CSS解释器工作完之后,在DOM树上附加解释后的样式信息,这就是RenderObject树
        3.RenderObject节点在创建的同时,WebKit会根据网页的层次结构创建RenderLayer树,同时构建一个虚拟的绘图上下文。
     
        RenderObject树的建立并不表示DOM树会被销毁,事实上,上述图中的四个内部表示结构一直存在,直到网页被销毁,因为它们对于网页的渲染起了非常大的作用。
        最后就是根据绘图上下文生成最终的图像,这一过程主要依赖2D和3D图形库,如下图:


     
        图中这一阶段对应的具体过程如下:
        
    1.绘图上下文是一个与平台无关的抽象类,它将每个绘图操作桥接到不同的具体实现类,也就是绘图具体实现类。
    2.绘图实现类也可能有简单的实现,也可能有复杂的实现。
    3.绘图实现类将2D图形库或者3D图形库绘制的结果保存下来,交给浏览器来同浏览器界面一起显示。
     
           这一过程实际上可能不像图中描述的那么简单,现代浏览器为了绘图上的高效性和安全性,可能会在这一过程中引入复杂的机制。而且,绘图也从之前单纯的软件渲染,到现在的GPU硬件渲染、混合渲染模型等方式。
       上面介绍的是一个完整的渲染过程。现代网页很多事动态网页,这意味着在渲染完成之后,由于网页的动画或者用户的交互,浏览器其实一直在不停地重复执行渲染过程。
    展开全文
  • vue页面的渲染过程

    千次阅读 2020-11-11 08:25:51
    本文主要介绍Vue页面的渲染过程 首先vue会找到webpack的打包配置文件。在build/webpack.base.conf.js下:在这里,定义了vue的程序入口文件 vue加载时文件的执行顺序 执行index.html文件 执行main.js文件 main....
    本文主要介绍Vue页面的渲染过程
    • 首先vue会找到webpack的打包配置文件。在build/webpack.base.conf.js下:在这里,定义了vue的程序入口文件

    vue加载时文件的执行顺序
    • 执行index.html文件
    • 执行main.js文件
    • main.js挂载了app.vue文件,用app.vue的templete替换index.html中的
    • main.js中注入了路由文件,将对应的组件渲染到router-view中
    • router-view中加载Layout文件
    • Layout 加载Navbar, Sidebar, AppMain

    vue内部页面的执行顺序
    Vue 推荐在绝大多数情况下使用 template 来创建你的 HTML。但是模板毕竟是模板,不是真实的dom节点。从模板到真实dom节点还需要经过一些步骤
    • 把模板编译为render函数
    • 实例进行挂载, 根据根节点render函数的调用,递归的生成虚拟dom
    • 对比虚拟dom,渲染到真实dom
    • 组件内部data发生变化,组件和子组件引用data作为props重新调用render函数,生成虚拟dom, 返回到步骤3

    一,模板到render

    // App.vue 
    <template>
        <div>
            hello word
        </div>
    </template>
    <script>
    export default {
    }
    </script>
    <style>
    </style>
    
    

    vue中各选项及钩子函数执行顺序

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    在页面首次加载执行顺序有如下:

    • beforeCreate //在实例初始化之后、创建之前执行
    • created //实例创建后执行
    • beforeMounted //在挂载开始之前调用
    • filters //挂载前加载过滤器
    • computed //计算属性
    • directives-bind //只调用一次,在指令第一次绑定到元素时调用
    • directives-inserted //被绑定元素插入父节点时调用
    • activated //keek-alive组件被激活时调用,则在keep-alive包裹的嵌套的子组件中触发
    • mounted //挂载完成后调用
    • {{}} //mustache表达式渲染页面

    修改页面input时,被自动调用的选项顺序如下:

    • watch //首先先监听到了改变事件
      filters //过滤器没有添加在该input元素上,但是也被调用了
    • beforeUpdate //数据更新时调用,发生在虚拟dom打补丁前
    • directived-update //指令所在的组件的vNode更新时调用,但可能发生在其子vNode更新前
    • directives-componentUpdated//指令所在的组件的vNode及其子组件的vNode全部更新后调用updated //组件dom已经更新

    组件销毁时,执行顺序如下

    • beforeDestroy //实例销毁之前调用
    • directives-unbind //指令与元素解绑时调用,只调用一次
    • deactivated //keep-alive组件停用时调用
    • destroyed //实例销毁之后调用
    展开全文
  • 在硬件加速渲染环境中,Android应用程序窗口的UI渲染是分两步进行的。第一步是构建Display List,发生在应用程序进程的Main Thread中;第二步是渲染Display List,发生在应用...本文就详细分析Display List的渲染过程

           在硬件加速渲染环境中,Android应用程序窗口的UI渲染是分两步进行的。第一步是构建Display List,发生在应用程序进程的Main Thread中;第二步是渲染Display List,发生在应用程序进程的Render Thread中。Display List的渲染不是简单地执行绘制命令,而是包含了一系列优化操作,例如绘制命令的合并执行。本文就详细分析Display List的渲染过程。

    老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注!

    《Android系统源代码情景分析》一书正在进击的程序员网(http://0xcc0xcd.com)中连载,点击进入!

           从前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文可以知道,Android应用程序窗口的Root Render Node的Display List,包含了Android应用程序窗口所有的绘制命令,因此我们只要对Root Render Node的Display List进行渲染,就可以得到整个Android应用程序窗口的UI。

           Android应用程序窗口的Display List的构建是通过Display List Renderer进行的,而渲染是通过Open GL Renderer进行的,如图1所示:


    图1 Android应用程序窗口的Display List的渲染示意图

           从图1可以知道,Open GL Renderer只作用在Android应用程序窗口的Root Render Node的Display List上,这是因为Root Render Node的Display List包含了Android应用程序窗口所有的绘制命令。

           Android应用程序窗口的Display List的渲染是由Render Thread执行的,不过是由Main Thread通知Render Thread执行的,如图2所示:


    图2 Main Thread向Render Thread发起渲染命令

          从图2可以知道。Main Thread通过向Render Thread的TaskQueue添加一个drawFrame任务来通知Render Thread渲染Android应用程序窗口的UI。

          从前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文还可以知道,Android应用程序窗口的Display List构建完成之后,Main Thread就马上向Render Thread发出渲染命令,如下所示:

    public class ThreadedRenderer extends HardwareRenderer {  
        ......  
      
        @Override  
        void draw(View view, AttachInfo attachInfo, HardwareDrawCallbacks callbacks) {  
            ......  
      
            updateRootDisplayList(view, callbacks);  
            ......  
      
            if (attachInfo.mPendingAnimatingRenderNodes != null) {  
                final int count = attachInfo.mPendingAnimatingRenderNodes.size();  
                for (int i = 0; i < count; i++) {  
                    registerAnimatingRenderNode(  
                            attachInfo.mPendingAnimatingRenderNodes.get(i));  
                }  
                attachInfo.mPendingAnimatingRenderNodes.clear();  
                // We don't need this anymore as subsequent calls to  
                // ViewRootImpl#attachRenderNodeAnimator will go directly to us.  
                attachInfo.mPendingAnimatingRenderNodes = null;  
            }  
      
            int syncResult = nSyncAndDrawFrame(mNativeProxy, frameTimeNanos,  
                    recordDuration, view.getResources().getDisplayMetrics().density);  
            if ((syncResult & SYNC_INVALIDATE_REQUIRED) != 0) {
                attachInfo.mViewRootImpl.invalidate();
            }
     
        }  
      
        ......  
    } 
           这个函数定义在文件frameworks/base/core/java/android/view/ThreadedRenderer.java中。

           ThreadedRenderer类的成员函数draw主要执行三个操作:

           1. 调用成员函数updateRootDisplayList构建或者更新应用程序窗口的Root Render Node的Display List。

           2. 调用成员函数registerAnimationRenderNode注册应用程序窗口动画相关的Render Node。

           3. 调用成员函数nSyncAndDrawFrame渲染应用程序窗口的Root Render Node的Display List。

           其中,第一个操作在前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文已经分析,第二个操作在接下来的一篇文章中分析,这篇文章主要关注第三个操作,即应用程序窗口的Root Render Node的Display List的渲染过程,即ThreadedRenderer类的成员函数nSyncAndDrawFrame的实现。

           ThreadedRenderer类的成员函数nSyncAndDrawFrame是一个JNI函数,由Native层的函数android_view_ThreadedRenderer_syncAndDrawFrame实现,如下所示:

    static int android_view_ThreadedRenderer_syncAndDrawFrame(JNIEnv* env, jobject clazz,
            jlong proxyPtr, jlong frameTimeNanos, jlong recordDuration, jfloat density) {
        RenderProxy* proxy = reinterpret_cast<RenderProxy*>(proxyPtr);
        return proxy->syncAndDrawFrame(frameTimeNanos, recordDuration, density);
    }

           这个函数定义在文件frameworks/base/core/jni/android_view_ThreadedRenderer.cpp中。

           参数proxyPtr描述的是一个RenderProxy对象,这里调用它的成员函数syncAndDrawFrame渲染应用程序窗口的Display List。

           RenderProxy类的成员函数syncAndDrawFrame的实现如下所示:

    int RenderProxy::syncAndDrawFrame(nsecs_t frameTimeNanos, nsecs_t recordDurationNanos,
            float density) {
        mDrawFrameTask.setDensity(density);
        return mDrawFrameTask.drawFrame(frameTimeNanos, recordDurationNanos);
    }
           这个函数定义在文件frameworks/base/libs/hwui/renderthread/RenderProxy.cpp。

           RenderProxy类的成员变量mDrawFrameTask指向的是一个DrawFrameTask对象。在前面Android应用程序UI硬件加速渲染环境初始化过程分析一文提到,这个DrawFrameTask对象描述的是一个用来执行渲染任务的Task,这里调用它的成员函数drawFrame渲染应用程序窗口的下一帧,也就是应用程序窗口的Display List。

           DrawFrameTask的成员函数drawFrame的实现如下所示:

    int DrawFrameTask::drawFrame(nsecs_t frameTimeNanos, nsecs_t recordDurationNanos) {
        ......
    
        mSyncResult = kSync_OK;
        ......
    
        postAndWait();
    
        ......
    
        return mSyncResult;
    }
            这个函数定义在文件frameworks/base/libs/hwui/renderthread/DrawFrameTask.cpp中。

            DrawFrameTask的成员函数drawFrame最主要的操作就是调用另外一个成员函数postAndWait往Render Thread的Task Queue抛一个消息,并且进入睡眠状态,等待Render Thread在合适的时候唤醒。

            DrawFrameTask的成员函数postAndWait的实现如下所示:

    void DrawFrameTask::postAndWait() {
        AutoMutex _lock(mLock);
        mRenderThread->queue(this);
        mSignal.wait(mLock);
    }
           这个函数定义在文件frameworks/base/libs/hwui/renderthread/DrawFrameTask.cpp中。

           由于DrawFrameTask类描述的就是一个可以添加到Render Thread的Task Queue的Task,因此DrawFrameTask的成员函数postAndWait就将当前正在处理的DrawFrameTask对象添加到由成员变量mRenderThread描述的Render Thread的Task Queue,并且在另外一个成员变量mSignal描述的一个条件变量上进行等待。

           从前面Android应用程序UI硬件加速渲染环境初始化过程分析一文可以知道,添加到Render Thread的Task Queue的Task被处理时,它的成员函数run就会被调用,因此接下来DrawFrameTask类的成员函数run就会被调用,它的实现如下所示:

    void DrawFrameTask::run() {
        ......
    
        bool canUnblockUiThread;
        bool canDrawThisFrame;
        {
            TreeInfo info(TreeInfo::MODE_FULL, mRenderThread->renderState());
            canUnblockUiThread = syncFrameState(info);
            canDrawThisFrame = info.out.canDrawThisFrame;
        }
    
        // Grab a copy of everything we need
        CanvasContext* context = mContext;
    
        // From this point on anything in "this" is *UNSAFE TO ACCESS*
        if (canUnblockUiThread) {
            unblockUiThread();
        }
    
        if (CC_LIKELY(canDrawThisFrame)) {
            context->draw();
        }
    
        if (!canUnblockUiThread) {
            unblockUiThread();
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/renderthread/DrawFrameTask.cpp中。

           要理解这个函数首先要理解应用程序进程的Main Thread和Render Thread是如何协作的。从前面的分析可以知道,Main Thread请求Render Thread执行Draw Frame Task的时候,不能马上返回,而是进入等待状态。等到Render Thread从Main Thread同步完绘制所需要的信息之后,Main Thread才会被唤醒。

           那么,Render Thread要从Main Thread同步什么信息呢?原来,Main Thread和Render Thread都各自维护了一份应用程序窗口视图信息。各自维护了一份应用程序窗口视图信息的目的,就是为了可以互不干扰,进而实现最大程度的并行。其中,Render Thread维护的应用程序窗口视图信息是来自于Main Thread的。因此,当Main Thread维护的应用程序窗口信息发生了变化时,就需要同步到Render Thread去。

           应用程序窗口的视图信息包含图1所示的各个Render Node的Display List、Property以及Display List引用的Bitmap。在RenderNode类中,有六个成员变量是与Display List和Property相关的,如下所示:

    class RenderNode : public VirtualLightRefBase {
    public:
        ......
    
        ANDROID_API void setStagingDisplayList(DisplayListData* newData);
        ......
    
        const RenderProperties& stagingProperties() {
            return mStagingProperties;
        }
        ......
    
    private:
        ......
    
        uint32_t mDirtyPropertyFields;
        RenderProperties mProperties;
        RenderProperties mStagingProperties;
    
        bool mNeedsDisplayListDataSync;
        // WARNING: Do not delete this directly, you must go through deleteDisplayListData()!
        DisplayListData* mDisplayListData;
        DisplayListData* mStagingDisplayListData;
     
        ......
    };
           这个类定义在文件frameworks/base/libs/hwui/RenderNode.h中。

           其中,成员变量mStagingProperties描述的Render Properties和成员变量mStagingDisplayListData描述的Display List Data由Main Thread维护,而成员变量mProperties描述的Render Properties和成员变量mDisplayListData描述的Display List Data由Render Thread维护。

           这一点可以从前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文看出。当Main Thread构建完成应用程序窗口的Display List之后,就会调用RenderNode类的成员函数setStagingDisplayList将其设置到Root Render Node的成员变量mStagingDisplayListData中去。而当应用程序窗口某一个View的Property发生变化时,就会调用RenderNode类的成员函数mutateStagingProperties获得成员变量mStagingProperties描述的Render Properties,进而修改相应的Property。

           当Main Thread维护的Render Properties发生变化时,成员变量mDirtyPropertyFields的值就不等于0,其中不等于0的位就表示是哪一个具体的Property发生了变化,而当Main Thread维护的Display List Data发生变化时,成员变量mNeedsDisplayListDataSync的值就等于true,表示要从Main Thread同步到Render Thread。

           另外,在前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文分析将一个Bitmap绘制命令转化为一个DrawBitmapOp记录在Display List时,Bitmap会被增加一个引用,如下所示:

    status_t DisplayListRenderer::drawBitmap(const SkBitmap* bitmap, const SkPaint* paint) {
        bitmap = refBitmap(bitmap);
        paint = refPaint(paint);
    
        addDrawOp(new (alloc()) DrawBitmapOp(bitmap, paint));
        return DrawGlInfo::kStatusDone;
    }
           这个函数定义在文件frameworks/base/libs/hwui/DisplayListRenderer.cpp中。

           参数bitmap描述的SkBitmap通过调用DisplayListRenderer类的成员函数refBitmap进行使用,它的实现如下所示:

    class ANDROID_API DisplayListRenderer: public StatefulBaseRenderer {
    public:
        ......
    
        inline const SkBitmap* refBitmap(const SkBitmap* bitmap) {
            ......
            mDisplayListData->bitmapResources.add(bitmap);
            mCaches.resourceCache.incrementRefcount(bitmap);
            return bitmap;
        }
    
        ......
    };
           这个函数定义在文件frameworks/base/libs/hwui/DisplayListRenderer.h中。

           DisplayListRenderer类的成员函数refBitmap在增加参数bitmap描述的一个SkBitmap的引用计数之前,会将它保存在成员变量mDisplayListData指向的一个DisplayListData对象的成员变量bitmapResources描述的一个Vector中。

           上述情况是针对调用GLES20Canvas类的以下成员函数drawBitmap绘制一个Bitmap时发生的情况:

    class GLES20Canvas extends HardwareCanvas {
        ......
    
        @Override
        public void drawBitmap(Bitmap bitmap, float left, float top, Paint paint) {
            throwIfCannotDraw(bitmap);
            final long nativePaint = paint == null ? 0 : paint.mNativePaint;
            nDrawBitmap(mRenderer, bitmap.mNativeBitmap, bitmap.mBuffer, left, top, nativePaint);
        }
    
        ......
    }
           这个函数定义在文件frameworks/base/core/java/android/view/GLES20Canvas.java。

           我们还可以调用GLES20Canvas类的另外一个重载版本的成员函数drawBitmap绘制一个Bitmap,如下所示:

    class GLES20Canvas extends HardwareCanvas {
        ......
    
        @Override
        public void drawBitmap(int[] colors, int offset, int stride, float x, float y,
                int width, int height, boolean hasAlpha, Paint paint) {
            ......
    
            final long nativePaint = paint == null ? 0 : paint.mNativePaint;
            nDrawBitmap(mRenderer, colors, offset, stride, x, y,
                    width, height, hasAlpha, nativePaint);
        }
    
        ......
    }
           这个函数定义在文件frameworks/base/core/java/android/view/GLES20Canvas.java。

           GLES20Canvas类这个重载版本的成员函数drawBitmap通过一个int数组来指定要绘制的Bitmap。这个int数组是由应用程序自己管理的,并且会被封装成一个SkBitmap,最终由DisplayListRenderer类的成员函数drawBitmapData将该Bitmap绘制命令封装成一个DrawBitmapDataOp记录在Display List中,如下所示:

    status_t DisplayListRenderer::drawBitmapData(const SkBitmap* bitmap, const SkPaint* paint) {
        bitmap = refBitmapData(bitmap);
        paint = refPaint(paint);
    
        addDrawOp(new (alloc()) DrawBitmapDataOp(bitmap, paint));
        return DrawGlInfo::kStatusDone;
    }
           这个函数定义在文件frameworks/base/libs/hwui/DisplayListRenderer.cpp中。

           DisplayListRenderer类的成员函数drawBitmapData通过另外一个成员函数refBitmapData来增加参数bitmap描述的SkBitmap的引用,如下所示:

    class ANDROID_API DisplayListRenderer: public StatefulBaseRenderer {
    public:
        ......
    
        inline const SkBitmap* refBitmapData(const SkBitmap* bitmap) {
            mDisplayListData->ownedBitmapResources.add(bitmap);
            mCaches.resourceCache.incrementRefcount(bitmap);
            return bitmap;
        }
    
        ......
    };
           这个函数定义在文件frameworks/base/libs/hwui/DisplayListRenderer.cpp中。

           与前面分析的DisplayListRenderer类的成员函数refBitmap不同,DisplayListRenderer类的成员函数refBitmapData将参数bitmap描述的SkBitmap保存在成员变量mDisplayListData指向的一个DisplayListData对象的成员变量ownedBitmapResources描述的一个Vector中。这是由于前者引用的SkBitmap使用的底层存储是由应用程序提供和管理的,而后者引用的SkBitmap使用的底层存储是在SkBitmap内部创建和管理的。这个区别在接下来分析Bitmap的同步过程时会进一步得到体现。

           Display List引用的Bitmap的同步方式与Display List和Render Property的同步方式有所不同。在同步Bitmap的时候,Bitmap将作为一个Open GL纹理上传到GPU去被Render Thread使用。

           有了这些背景知识之后 ,再回到DrawFrameTask类的成员函数run中,它的执行逻辑如下所示:

           1. 调用成员函数syncFrameState将应用程序窗口的Display List、Render Property以及Display List引用的Bitmap等信息从Main Thread同步到Render Thread中。注意,在这个同步过程中,Main Thread是处于等待状态的。

           2. 如果成员函数syncFrameState能顺利地完成信息同步,那么它的返回值canUnblockUiThread就会等于true,表示在Render Thread渲染应用程序窗口的下一帧之前,就可以唤醒Main Thread了。否则的话,就要等到Render Thread渲染应用程序窗口的下一帧之后,才能唤醒Main Thread。唤醒Render Thread是通过调用成员函数unblockUiThread来完成的,如下所示:

    void DrawFrameTask::unblockUiThread() {
        AutoMutex _lock(mLock);
        mSignal.signal();
    }
           这个函数定义在frameworks/base/libs/hwui/renderthread/DrawFrameTask.cpp中。

           前面Main Thread就刚好是等待在DrawFrameTask类的成员变量mSignal描述的一个条件变量之上的,所以现在Render Thread就通过这个条件变量来唤醒它。

           3. 调用成员变量mContext描述的一个CanvasContext对象的成员函数draw渲染应用程序窗口的Display List,不过前提是当前帧能够进行绘制。什么时候当前帧不能够进行绘制呢?我们知道,应用程序进程绘制好一个窗口之后,得到的图形缓冲区要交给Surface Flinger进行合成,最后才能显示在屏幕上。Surface Flinger为每一个窗口都维护了一个图形缓冲区队列。当这个队列等待合成的图形缓冲区的个数大于等于2时,就表明Surface Flinger太忙了。因此这时候就最好不再向它提交图形缓冲区,这就意味着应用程序窗口的当前帧不能绘制了,也就是会被丢弃。

           注意,Render Thread渲染应用程序窗口的Display List的时候,Main Thread有可能是处于等待状态,也有可能不是处于等待状态。这取决于前面的信息同步结果。信息同步结果是通过一个TreeInfo来描述的。当Main Thread不是处于等待状态时,它就可以马上处理其它事情了,例如构建应用程序窗口下一帧时使用的Display List。这样就可以做到Render Thread在绘制应用程序窗口的当前帧的同时,Main Thread可以并行地去构建应用程序窗口的下一帧的Display List。这一点也是Android 5.0引进Render Thread的好处所在。

           接下来,我们就先分析应用程序窗口绘制信息的同步过程,即DrawFrameTask类的成员函数syncFrameState的实现,接着再分析应用程序窗口的Display List的渲染过程,即CanvasContext类的成员函数draw的实现。

           DrawFrameTask类的成员函数syncFrameState的实现如下所示:

    bool DrawFrameTask::syncFrameState(TreeInfo& info) {
        ......
       
        Caches::getInstance().textureCache.resetMarkInUse();
    
        for (size_t i = 0; i < mLayers.size(); i++) {
            mContext->processLayerUpdate(mLayers[i].get());
        }
        ......
        mContext->prepareTree(info);
    
        if (info.out.hasAnimations) {
            if (info.out.requiresUiRedraw) {
                mSyncResult |= kSync_UIRedrawRequired;
            }
        }
        // If prepareTextures is false, we ran out of texture cache space
        return info.prepareTextures;
    }
           这个函数定义在文件frameworks/base/libs/hwui/renderthread/DrawFrameTask.cpp中。

           应用程序进程有一个Caches单例。这个Caches单例有一个成员变量textureCache,它指向的是一个TextureCache对象。这个TextureCache对象用来缓存应用程序窗口在渲染过程中用过的Open GL纹理。在同步应用程序窗口绘制信息之前,DrawFrameTask类的成员函数syncFrameState首先调用这个TextureCache对象的成员函数resetMarkInUse将缓存的Open GL纹理标记为未使用状态。

           在前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文提到,当TextureView有更新时,Native层会将一个与它关联的DeferredLayerUpdater对象保存在DrawFrameTask类的成员变量mLayers描述的一个vector中。也就是说,保存在这个vector中的DeferredLayerUpdater对象,都是需要进一步处理的。需要做的处理就是从与TextureView关联的SurfaceTexture中读出下一个可用的图形缓冲区,并且将该图形缓冲区封装成一个Open GL纹理。这是通过调用DrawFrameTask类的成员变量mContext指向的一个CanvasContext对象的成员函数processLayerUpdate来实现的。

           CanvasContext类的成员函数processLayerUpdate的实现如下所示:

    void CanvasContext::processLayerUpdate(DeferredLayerUpdater* layerUpdater) {
        bool success = layerUpdater->apply();
        ......
    }
           这个函数定义在文件frameworks/base/libs/hwui/renderthread/CanvasContext.cpp中。

           CanvasContext类的成员函数processLayerUpdate主要是调用参数layerUpdater描述的一个DeferredLayerUpdater对象的成员函数apply读出下一个可用的图形缓冲区,并且将该图形缓冲区封装成一个Open GL纹理,以便后面可以对它进行渲染。   

           DeferredLayerUpdater类的成员函数apply的实现如下所示:

    bool DeferredLayerUpdater::apply() {
        bool success = true;
        ......
    
        if (mSurfaceTexture.get()) {
            ......
            if (mUpdateTexImage) {
                mUpdateTexImage = false;
                doUpdateTexImage();
            }
            ......
        }
        return success;
    }
           这个函数定义在文件frameworks/base/libs/hwui/DeferredLayerUpdater.cpp中。

           DeferredLayerUpdater类的成员变量mSurfaceTexture指向的一个是GLConsumer对象。这个GLConsumer对象用来描述与当前正在处理的DeferredLayerUpdater对象关联的TextureView对象所使用的一个SurfaceTexture对象的读端。也就是说,通过这个GLConsumer对象可以将关联的TextureView对象的下一个可用的图形缓冲区读取出来。

           从前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文可以知道,当一个TextureView有可用的图形缓冲区时,与它关联的DeferredLayerUpdater对象的成员变量mUpdateTexImage值会被设置为true。这时候如果当前正在处理的DeferredLayerUpdater对象的成员变量mSurfaceTexture指向了一个GLConsumer对象,那么现在就是时候去读取可用的图形缓冲区了。这是通过调用DeferredLayerUpdater类的成员函数doUpdateTexImage来实现的。

           DeferredLayerUpdater类的成员函数doUpdateTexImage的实现如下所示:

    void DeferredLayerUpdater::doUpdateTexImage() {
        if (mSurfaceTexture->updateTexImage() == NO_ERROR) {
            ......
    
            GLenum renderTarget = mSurfaceTexture->getCurrentTextureTarget();
    
            LayerRenderer::updateTextureLayer(mLayer, mWidth, mHeight,
                    !mBlend, forceFilter, renderTarget, transform);
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/DeferredLayerUpdater.cpp中。

           DeferredLayerUpdater类的成员函数doUpdateTexImage调用成员变量mSurfaceTexture指向的一个GLConsumer对象的成员函数updateTexImage读出可用的图形缓冲区,并且将该图形缓冲区封装成一个Open GL纹理。这个Open GL纹理可以通过调用上述的GLConsumer对象的成员函数getCurrentTextureTarget获得了。

           接下来DeferredLayerUpdater类的成员函数doUpdateTexImage调用LayerRenderer类的静态成员函数updateTextureLayer将获得的Open GL纹理关联给成员变量mLayer描述的一个Layer对象。

           LayerRenderer类的静态成员函数updateTextureLayer的实现如下所示:

    void LayerRenderer::updateTextureLayer(Layer* layer, uint32_t width, uint32_t height,
            bool isOpaque, bool forceFilter, GLenum renderTarget, float* textureTransform) {
        if (layer) {
            ......
    
            if (renderTarget != layer->getRenderTarget()) {
                layer->setRenderTarget(renderTarget);
                ......
            }
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/LayerRenderer.cpp中。

           LayerRenderer类的静态成员函数updateTextureLayer主要就是将参数renderTarget描述的Open GL纹理设置给参数layer描述的Layer对象。这是通过调用Layer类的成员函数setRenderTarget实现的。一个Layer对象关联了Open GL纹理之后,以后就可以进行渲染了。

           这一步执行完成之后,如果应用程序窗口存在需要更新的TextureView,那么这些TextureView就更新完毕,也就是这些TextureView下一个可用的图形缓冲区已经被读出,并且封装成了Open GL纹理。回到前面分析的DrawFrameTask类的成员函数syncFrameState中,接下来要做的事情是将Main Thread维护的Display List等信息同步到Render Thread中。这是通过调用DrawFrameTask类的成员变量mContext指向的一个CanvasContext对象的成员函数prepareTree实现的。

           CanvasContext对象的成员函数prepareTree执行完毕之后,会通过参数info描述的一个TreeInfo对象返回一些同步结果:

           1. 当这个TreeInfo对象的成员变量out指向的一个Out对象的成员变量hasAnimations等于true时,表示应用程序窗口存在未完成的动画。如果这些未完成的动画至少存在一个是非异步动画时,上述Out对象的成员变量requiresUiRedraw的值就会被设置为true。这时候DrawFrameTask类的成员变量mSyncResult的kSync_UIRedrawRequired位就会被设置为1。所谓非异步动画,就是那些在执行过程可以停止的动画。这个停止执行的逻辑是由Main Thread执行的,例如,Main Thread可以响应用户输入停止执行一个非异步动画。从前面分析可以知道,DrawFrameTask类的成员变量mSyncResult的值最后将会返回给Java层的ThreadedRenderer类的成员函数draw。ThreadedRenderer类的成员函数draw一旦发现该值的kSync_UIRedrawRequired位被设置为1,那么就会向Main Thread的消息队列发送一个INVALIDATE消息,以便在处理这个INVALIDATE消息的时候,可以响应停止执行非异步动画的请求。

           2. 当这个TreeInfo对象的成员变量prepareTextures的值等于true时,表示应用程序窗口的Display List引用到的Bitmap均已作为Open GL纹理上传到了GPU。这意味着应用程序窗口的Display List引用到的Bitmap已全部同步完成。在这种情况下,Render Thread在渲染下一帧之前,就可以唤醒Main Thread。另一方面,如果上述TreeInfo对象的成员变量prepareTextures的值等于false,就意味着应用程序窗口的Display List引用到的某些Bitmap不能成功地作为Open GL纹理上传到GPU,这时候Render Thread在渲染下一帧之后,才可以唤醒Main Thread,防止这些未能作为Open GL纹理上传到GPU的Bitmap一边被Render Thread渲染,一边又被Main Thread修改。那么什么时候应用程序窗口的Display List引用到的Bitmap会不能成功地作为Open GL纹理上传到GPU呢?一个应用程序进程可以创建的Open GL纹理是有大小限制的,如果超出这个限制,那么就会导至某些Bitmap不能作为Open GL纹理上传到GPU。

           接下来,我们就继续分析CanvasContext类的成员函数prepareTree的实现,以便可以了解应用程序窗口的Display List等信息的同步过程,如下所示:

    void CanvasContext::prepareTree(TreeInfo& info) {
        ......
    
        info.renderer = mCanvas;
        ......
    
        mRootRenderNode->prepareTree(info);
    
        ......
    
        int runningBehind = 0;
        // TODO: This query is moderately expensive, investigate adding some sort
        // of fast-path based off when we last called eglSwapBuffers() as well as
        // last vsync time. Or something.
        mNativeWindow->query(mNativeWindow.get(),
                NATIVE_WINDOW_CONSUMER_RUNNING_BEHIND, &runningBehind);
        info.out.canDrawThisFrame = !runningBehind;
    
        if (info.out.hasAnimations || !info.out.canDrawThisFrame) {
            if (!info.out.requiresUiRedraw) {
                // If animationsNeedsRedraw is set don't bother posting for an RT anim
                // as we will just end up fighting the UI thread.
                mRenderThread.postFrameCallback(this);
            }
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           CanvasContext类的成员变量mRootRenderNode指向的一个RenderNode对象描述的是应用程序窗口的Root Render Node,这里通过调用它的成员函数prepareTree开始对应用程序窗口的各个View的Display List进行同步。

           在这个同步的过程中,如果某些View设置了动画,并且这些动还未执行完成,那么参数info指向的TreeInfo对象的成员变量hasAnimations的值就会等于true。这时候如果应用程序窗口的下一帧不可以渲染,即上述TreeInfo对象的成员变量canDrawThisFrame的值等于false,并且所有View设置的动画都是非异步的,即上述TreeInfo对象的成员变量requiresUiRedraw的值等于false,那么就需要解决一个问题,那些未执行完成的动画如何继续执行下去?因为等到当应用程序窗口的下一帧可以渲染时,这些未完成的动画还是需要继续执行的。

           我们知道,当TreeInfo对象的成员变量requiresUiRedraw的值等于true时,Main Thread会自动发起渲染应用程序窗口的Display List的命令。在这个命令的执行过程中,未完成的动画是可以继续执行的。但是当TreeInfo对象的成员变量requiresUiRedraw的值等于false时,Main Thread不会自动发起渲染应用程序窗口的Display List的命令,这时候就需要向Render Thread注册一个IFrameCallback接口,这是通过调用CanvasContext类的成员变量mRenderThread指向的一个RenderThread对象的成员函数postFrameCallback实现的

           从前面Android应用程序UI硬件加速渲染环境初始化过程分析一文可以知道,注册到Render Thread的IFrameCallback接口在下一个Vsync信号到来时,它的成员函数doFrame会被调用,这时候就可以执行渲染应用程序窗口的下一帧了。在渲染的过程中,就可以继续执行那些未完成的动画了。

           CanvasContext类的成员变量mNativeWindow描述的就是当前绑定的应用程序窗口,通过调用它的成员函数query,并且将第二个参数设置为NATIVE_WINDOW_CONSUMER_RUNNING_BEHIND,可以查询到它提交了多少个图形缓冲区还未被处理。如果这些已提交了但是还没有被处理的图形缓冲区大于等于2,输出参数runningBehind就会等于true,这表明Surface Flinger太忙了,这时候应用程序窗口就应该丢弃当前帧,因此就将参数info指向的TreeInfo对象的成员变量canDrawThisFrame的值设置为false。

           接下来我们继续分析RenderNode类的成员函数prepareTree的实现,以便可以了解对应用程序窗口的各个View的Display List的同步过程,如下所示:

    void RenderNode::prepareTree(TreeInfo& info) {
        ......
    
        prepareTreeImpl(info);
    }
           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           RenderNode类的成员函数prepareTree调用另外一个成员函数prepareTreeImpl来同步当前正在处理的Render Node的Display List等信息,后者的实现如下所示:

    void RenderNode::prepareTreeImpl(TreeInfo& info) {
        ......
    
        if (info.mode == TreeInfo::MODE_FULL) {
            pushStagingPropertiesChanges(info);
        }
        uint32_t animatorDirtyMask = 0;
        if (CC_LIKELY(info.runAnimations)) {
            animatorDirtyMask = mAnimatorManager.animate(info);
        }
        ......
        if (info.mode == TreeInfo::MODE_FULL) {
            pushStagingDisplayListChanges(info);
        }
        prepareSubTree(info, mDisplayListData);
        pushLayerUpdate(info);
    
        ......
    }

           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           从前面分析的DrawFrameTask类的成员函数run可以知道,参数info指向的TreeInfo对象的成员变量mode的值等于TreeInfo::MODE_FULL,这意味着RenderNode类的成员函数prepareTreeImpl执行在同步模式中,这时候它将会执行以下五个操作:

           1. 调用成员函数pushStagingPropertiesChanges同步当前正在处理的Render Node的Property。

           2. 在参数info指向的TreeInfo对象的成员变量runAnitmations的值等于true的前提下,调用成员变量mAnimatorManager指向的一个AnimatorManager对象的成员函数animate执行动画相关的操作。

           3. 调用成员函数pushStagingDisplayListChanges同步当前正在处理的Render Node的Display List。

           4. 调用成员函数prepareSubTree同步当前正在处理的Render Node的Display List引用的Bitmap,以及当前正在处理的Render Node的子Render Node的Display List等信息。

           5. 调用成员函数pushLayerUpdate检查当前正在处理的Render Node是否设置了Layer。如果设置了的话,就对这些Layer进行处理。

           其中,第2个操作是与动画显示相关的,我们在接下来的一篇文章再详细分析。

           与第1个操作相关的函数是RenderNode类的成员函数pushStagingPropertiesChanges,它的实现如下所示:

    void RenderNode::pushStagingPropertiesChanges(TreeInfo& info) {
        ......
    
        if (mDirtyPropertyFields) {
            mDirtyPropertyFields = 0;
            ......
            mProperties = mStagingProperties;
            ......
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           前面提到,当RenderNode类的成员变量mDirtyPropertyFields的值不等于0时,就表明Main Thread维护的Render Node的Property发生了变化,因此就需要将它同步到Render Thread去,也就是将成员变量mStagingProperties描述的RenderProperties对象转移到成员变量mProperties去。

           与第3个操作相关的函数是RenderNode类的成员函数pushStagingDisplayListChanges,它的实现如下所示:

    void RenderNode::pushStagingDisplayListChanges(TreeInfo& info) {
        if (mNeedsDisplayListDataSync) {
            mNeedsDisplayListDataSync = false;
            ......
            deleteDisplayListData();
            mDisplayListData = mStagingDisplayListData;
            mStagingDisplayListData = NULL;
            if (mDisplayListData) {
                for (size_t i = 0; i < mDisplayListData->functors.size(); i++) {
                    (*mDisplayListData->functors[i])(DrawGlInfo::kModeSync, NULL);
                }
            }
            ......
        }
    }

           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           前面提到,当RenderNode类的成员变量mNeedsDisplayListDataSync的值等于true时,就表明Main Thread维护的Render Node的Display List发生了变化,因此就需要将它同步到Render Thread去,也就是将成员变量mStagingDisplayListData描述的DisplayListData对象转移到成员变量mDisplayListData去。

           在将成员变量mStagingDisplayListData描述的DisplayListData对象转移到成员变量mDisplayListData去之前,首先会调用成员函数deleteDisplayListData删除成员变量mDisplayListData原先描述的DisplayListData对象。

           记录在Display List Data的绘制命令除了是一些普通的DrawOp之外,还可能是一些函数指针,这些函数指针保存在Display List Data的成员变量functors描述的一个Vector中。这些函数指针是做什么用的呢?有些绘制命令很复杂,是不能通过一个简单的DrawOp来描述的,例如它是由一系列简单的绘制命令以复杂方式组合在一起形成的。对于这些复杂的绘制命令,我们就可以通过一个函数指针来描述。当Render Thread渲染应用程序窗口的Display List遇到这些函数指针时,就会调用这些函数指针指向的函数,这样这些函数就可以在其内部实现复杂的绘制命令,或者说是完成自定义的绘制命令。

           这些函数指针在应用程序窗口的Display List的渲染过程中,会被调用两次。第一次调用时,第一个参数指定为DrawGlInfo::kModeSync,表示这时候它可以执行一些同步相关的操作。第二次调用时,第二个参数指定为DrawGlInfo::kModeDraw,表示这时候可以执行一些与渲染相关的操作。

           此外,我们还可以通过Java层的ThreadedRenderer类的静态成员函数invokeFunctor将一个函数指定在Render Thread执行。例如,我们希望在应用程序进程中执行一些Open GL相关的操作时,就可以将这些操作封装在一个函数中,并且将该函数的地址封装成一个Task发送到Render Thread的Task Queue中。当这个Task被Render Thread处理的时候,封装在这个Task里面的函数就会被执行。这时候传递给这些函数的第一个参数就为DrawGlInfo::kModeProcess或者DrawGlInfo::kModeProcessNoContext。其中,DrawGlInfo::kModeProcess表示Render Thread已经初好了Open GL环境,而DrawGlInfo::kModeProcessNoContext表示Render Thread还没有初始化Open GL环境。

           将函数指针记录Display List中交给Main Thread和Render Thread执行以及将函数指针封装成Task交给Render Thread执行的设计主要是为了实现WebView功能的。Android系统从4.4开始,通过Chromium来实现WebView的功能。Chromium有一套非常复杂的网页渲染机制,当它通过WebView嵌入在应用程序进程执行时,就会需要利用Render Thread可以执行Open GL操作的能力来完成它自己的功能。由这些网页渲染操作很复杂,因此就最好是通过函数来描述,这样就产生了能够将函数指定在Render Thread执行的需求。以后如果有机会分析WebView然Chromium版实现,我们就会看到这一套机制是如何运行的。

           回到RenderNode类的成员函数prepareTree中,与第4个操作相关的函数是RenderNode类的成员函数prepareSubTree,它的实现如下所示:

    void RenderNode::prepareSubTree(TreeInfo& info, DisplayListData* subtree) {
        if (subtree) {
            TextureCache& cache = Caches::getInstance().textureCache;
            ......
            if (subtree->ownedBitmapResources.size()) {
                info.prepareTextures = false;
            }
            for (size_t i = 0; info.prepareTextures && i < subtree->bitmapResources.size(); i++) {
                info.prepareTextures = cache.prefetchAndMarkInUse(subtree->bitmapResources[i]);
            }
            for (size_t i = 0; i < subtree->children().size(); i++) {
                DrawRenderNodeOp* op = subtree->children()[i];
                RenderNode* childNode = op->mRenderNode;
                ......
                childNode->prepareTreeImpl(info);
                .....
            }
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           前面提到,Display List引用的Bitmap保存在它的成员变量ownedBitmapResources和bitmapResources的两个Vector中。其中,保存在Display List的成员变量ownedBitmapResources中的Bitmap的底层储存是由应用程序提供和管理的。这意味着很难维护该底层储存在Main Thread和Render Thread的一致性。例如,有可能应用程序自行修改了该底层储存的内容,但是又没有通知Render Thread进行同步。因此,当存在这样的Bitmap时,就不允许Render Thread在渲染完成应用程序窗口的一帧之前唤醒Main Thread,就是为了防止Main Thread会修改上述Bitmap的底层储存。为了达到这个目的,这时候就需要将参数info指向的一个TreeInfo对象的成员变量prepareTextures的值设置为false。

           另一方面,保存在Display List的成员变量bitmapResources中的Bitmap的底层储存不是由应用程序提供和管理的,因此就能够保证它不会被随意修改而又不通知Render Thread进行同步。对于这些Bitmap,就可以将它们作为Open GL纹理上传到GPU去。这就相当于是将Bitmap从Main Thread同步到Render Thread中,因为Render Thread就通过已经上传到GPU的Open GL纹理来使用这些Bitmap。能够执行这样的同步操作的前提是Display List的成员变量ownedBitmapResources描述的Vector为空。因为当Display List的成员变量ownedBitmapResources描述的Vector不为空时,Main Thread和Render Thread在渲染应用程序窗口的一帧时是完全同步的,因此就没有必要将Bitmap从Main Thread同步到Render Thread去。

           此外,对于保存在Display List的成员变量bitmapResources中的Bitmap,由于内存大小的限制,因此就不是所有的这些Bitmap都是能够作为Open GL纹理上传到GPU去的。一旦某一个Bitmap不能作为Open GL纹理上传到GPU去,那么也是需要完全同步Main Thread和Render Thread渲染应用程序窗口的一帧的。这时候就需要将参数info指向的一个TreeInfo对象的成员变量prepareTextures的值设置为false。

           同步完成当前正在处理的Render Node的Display List引用的Bitmap之后,接下来RenderNode类的成员函数prepareSubTree就调用前面分析过的成员函数prepareTreeImpl来同步当前在处理的Render Node的子Render Node的Display List、Property和Display List引用的Bitmap等信息。这个过程是一直归递执行下去,直到应用程序窗口视图结构中的每一个Render Node的isplay List、Property和Display List引用的Bitmap等信息都从Main Thread同步到Render Thread为止。

          上面提到的将Bitmap封装成Open GL纹理上传到GPU是通过调用TextureCache类的成员函数prefetchAndMarkInUse来实现的,如下所示:

    bool TextureCache::prefetchAndMarkInUse(const SkBitmap* bitmap) {
        Texture* texture = getCachedTexture(bitmap);
        if (texture) {
            texture->isInUse = true;
        }
        return texture;
    }
           这个函数定义在文件frameworks/base/libs/hwui/TextureCache.cpp中。

           TextureCache类的成员函数prefetchAndMarkInUse调用另外一个成员函数getCachedTexture将参数bitmap描述的Bitmap封装成Open Gl纹理上传到GPU中。如果能够上传成功,那么就可以获得一个Texture对象。TextureCache类的成员函数prefetchAndMarkInUse在将这个Texture对象返回给调用者之前,需要将它的成员变量isInUse设置为true,表示该Texture对象正在使用当中。

           TextureCache类的成员函数getCachedTexture的实现如下所示:

    Texture* TextureCache::getCachedTexture(const SkBitmap* bitmap) {
        Texture* texture = mCache.get(bitmap->pixelRef());
    
        if (!texture) {
            if (!canMakeTextureFromBitmap(bitmap)) {
                return NULL;
            }
    
            const uint32_t size = bitmap->rowBytes() * bitmap->height();
            bool canCache = size < mMaxSize;
            // Don't even try to cache a bitmap that's bigger than the cache
            while (canCache && mSize + size > mMaxSize) {
                Texture* oldest = mCache.peekOldestValue();
                if (oldest && !oldest->isInUse) {
                    mCache.removeOldest();
                } else {
                    canCache = false;
                }
            }
    
            if (canCache) {
                texture = new Texture();
                texture->bitmapSize = size;
                generateTexture(bitmap, texture, false);
    
                mSize += size;
                ......
                mCache.put(bitmap->pixelRef(), texture);
            }
        } else if (!texture->isInUse && bitmap->getGenerationID() != texture->generation) {
            // Texture was in the cache but is dirty, re-upload
            // TODO: Re-adjust the cache size if the bitmap's dimensions have changed
            generateTexture(bitmap, texture, true);
        }
    
        return texture;
    }
           这个函数定义在文件frameworks/base/libs/hwui/TextureCache.cpp中。

           每一个Bitmap作为Open GL纹理上传到GPU后,都会为其创建一个Texture对象。这些Texture对象就保存在TextureCache类通过成员变量mCache指向的一个LruCache中。因此,当不能够在该LruCache中找到参数bitmap描述的Bitmap对应的Texture对象时,就说明该Bitmap还未作为Open GL纹理上传到过GPU中,因此接下来就需要将它作为Open GL纹理上传到GPU去。

           但是参数bitmap描述的Bitmap却不一定能够成功作为Open GL纹理上传到GPU去,有两个原因:

           1. Bitmap太大,超出预先设定的最大Open GL纹理的大小。这种情况通过调用TextureCache类的成员函数canMakeTextureFromBitmap进行判断。

           2. 已经作为Open GL纹理上传到GPU的Bitmap太多,超出预先设定的最多可以上传到GPU的大小。

           在第2种情况下,这时候TextureCache类的成员函数getCachedTexture会尝试删掉那些最早上传到GPU的现在还不处于使用状态的Open GL纹理,直到能满足将参数bitmap描述的Bitmap作为Open GL纹理上传到GPU为止。

           一旦确定能够将参数bitmap描述的Bitmap作为Open GL纹理上传到GPU,那么就会调用TextureCache类的成员函数generateTexture执行具体的操作,并且创建为其创建一个Texture对象保存在成员变量mCache指向的一个LruCache中。

           另一方面,如果参数bitmap描述的Bitmap之前已经作为Open GL纹理上传到过GPU中,由于现在它的内容可能已经发生了变化,因此也需要调用TextureCache类的成员函数generateTexture执行重新上传的操作。

           回到RenderNode类的成员函数prepareTree中,与第5个操作相关的函数是RenderNode类的成员函数pushLayerUpdate,它的实现如下所示:

    void RenderNode::pushLayerUpdate(TreeInfo& info) {
        LayerType layerType = properties().layerProperties().type();
        ......
        if (CC_LIKELY(layerType != kLayerTypeRenderLayer) || CC_UNLIKELY(!isRenderable())) {
            if (CC_UNLIKELY(mLayer)) {
                LayerRenderer::destroyLayer(mLayer);
                mLayer = NULL;
            }
            return;
        }
    
        ......
    
        if (!mLayer) {
            mLayer = LayerRenderer::createRenderLayer(info.renderState, getWidth(), getHeight());
            ......
        } else if (mLayer->layer.getWidth() != getWidth() || mLayer->layer.getHeight() != getHeight()) {
            if (!LayerRenderer::resizeLayer(mLayer, getWidth(), getHeight())) {
                ......
            }
            ......
        }
    
        SkRect dirty;
        info.damageAccumulator->peekAtDirty(&dirty);
    
        ......
    
        if (dirty.intersect(0, 0, getWidth(), getHeight())) {
            ......
            mLayer->updateDeferred(this, dirty.fLeft, dirty.fTop, dirty.fRight, dirty.fBottom);
        }
    
        ......
    
        if (info.renderer && mLayer->deferredUpdateScheduled) {
            info.renderer->pushLayerUpdate(mLayer);
        }
    
        ......
    }
           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           在分析RenderNode类的成员函数pushLayerUpdate的实现之前,我们首先要理解什么情况下一个Render Node会被设置为一个Layer。

           当一个View的类型被设置为LAYER_TYPE_HARDWARE时,如果它的成员函数buildLayer被调用,那么与它关联的Render Node就会被设置为一个Layer。这意味着该View将会作为一个FBO(Frame Buffer Object)进行渲染。这样做主要是为了更流畅地显示一个View的动画。这一点我们在前面Android应用程序UI硬件加速渲染技术简要介绍和学习计划一文中曾经提到。

           有了这个背景知识之后,我们就可以分析RenderNode类的成员函数pushLayerUpdate的实现了。

           RenderNode类的成员函数pushLayerUpdate首先是判断当前正在处理的Render Node的Layer Type是否为kLayerTypeRenderLayer,也就是判断与它关联的View的类型是否设置为LAYER_TYPE_HARDWARE。如果不是,那么就不用往下执行了,因为这种情况当前正在处理的Render Node不可能设置为一个Layer。

           另一方面,如果当前正在处理的Render Node的Display List还没有创建或者是空的,那么RenderNode类的成员函数pushLayerUpdate也不用往下执行了,因为这种情况当前正在处理的Render Node是无需要渲染的。判断当前正在处理的Render Node的Display List有没有创建或者是不是空的,可以通过调用RenderNode类的成员函数isRenderable来实现。

           在上述两种情况下,RenderNode类的成员函数pushLayerUpdate在返回之前,会判断一下之前是否已经为当前正在处理的Render Node创建过Layer。如果创建过,那么就会调用LayerRenderer类的静态成员函数destroyLayer来销毁该Layer。

           接下来就是当前正在处理的Render Node需要设置为一个Layer的情况了。如果当前正在处理的Render Node还没有设置过Layer,也就是它的成员变量mLayer的值等于NULL,那么就调用LayerRenderer类的静态成员函数createRenderLayer为它设置一个,也就是创建一个Layer对象,并且保存在它的成员变量mLayer中。

           另一方面,如果当前正在处理的Render Node之前已经设置过Layer,但是该Layer的大小与当前正在处理的Render Node的大小不一致,那么就需要调用LayerRenderer类的静态成员函数resizeLayer调整廖Layer的大小。

           再接下来是计算当前正在处理的Render Node是否在应用程序窗口当前要更新的脏区域中。如果在的话,那么就需要调用与它关联的Layer对象的成员函数updateDeferred来标记与它关联的Layer对象是需要进行更新处理的。

           Layer类的成员函数updateDeferred的实现如下所示:

    void Layer::updateDeferred(RenderNode* renderNode, int left, int top, int right, int bottom) {
        requireRenderer();
        this->renderNode = renderNode;
        const Rect r(left, top, right, bottom);
        dirtyRect.unionWith(r);
        deferredUpdateScheduled = true;
    }
          这个函数定义在文件frameworks/base/libs/hwui/Layer.cpp中。

          Layer类的成员函数updateDeferred首先是调用另外一个成员函数requireRenderer检查当前正在处理的Layer对象是否已经创建有一个LayerRenderer对象了。这个LayerRenderer对象就是负责渲染当前正在处理的Layer对象的。如果还没有创建,那么就需要创建。如下所示:

    void Layer::requireRenderer() {
        if (!renderer) {
            renderer = new LayerRenderer(renderState, this);
            ......
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/Layer.cpp中。

           Layer类的成员函数updateDeferred接下来再记录当前正在处理的Layer对象关联的Render Node,并且更新它的脏区域,最后将成员变量deferredUpdateScheduled设置为true,表示当前正在处理的Layer对象后面还需要执行真正的更新操作,而这里只是记录了相关的更新状态信息而已。

           这一步执行完成后,回到RenderNode类的成员函数pushLayerUpdate中,这时候成员变量mLayer指向的Layer对象的成员变量deferredUpdateScheduled的值是等于true的,并且参数info指向的一个TreeInfo对象的成员变量renderer的值不为空,它指向了一个OpenGLRenderer对象,因此接下来就会调用该OpenGLRenderer对象的成员函数pushLayerUpdate来将成员变量mLayer指向的Layer对象记录在内部的一个待更新的Layer列表中,如下所示:

    void OpenGLRenderer::pushLayerUpdate(Layer* layer) {
        if (layer) {
            ......
            for (int i = mLayerUpdates.size() - 1; i >= 0; i--) {
                if (mLayerUpdates.itemAt(i) == layer) {
                    return;
                }
            }
            mLayerUpdates.push_back(layer);
            ......
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/OpenGLRenderer.cpp中。

           OpenGLRenderer类将需要进行更新处理的Layer对象保存在成员变量mLayerUpdates描述的一个Vector中,保存在这个Vector中的Layer对象在渲染应用程序窗口的Display List的时候,就是需要进行更新处理的。

           这一步执行完成之后,应用程序窗口的Display List等信息就从Main Thread同步到Render Thread了,回到DrawFrameTask类的成员函数run中,接下来就可以调用CanvasContext类的成员函数draw渲染应用程序窗口的Display List了。

           CanvasContext类的成员函数draw的实现如下所示:

    void CanvasContext::draw() {
        ......
    
        SkRect dirty;
        mDamageAccumulator.finish(&dirty);
    
        ......
    
        status_t status;
        if (!dirty.isEmpty()) {
            status = mCanvas->prepareDirty(dirty.fLeft, dirty.fTop,
                    dirty.fRight, dirty.fBottom, mOpaque);
        } else {
            status = mCanvas->prepare(mOpaque);
        }
    
        Rect outBounds;
        status |= mCanvas->drawRenderNode(mRootRenderNode.get(), outBounds);
    
        ......
    
        mCanvas->finish();
    
        ......
    
        if (status & DrawGlInfo::kStatusDrew) {
            swapBuffers();
        }
    
        ......
    }

           这个函数定义在文件frameworks/base/libs/hwui/OpenGLRenderer.cpp中。

           CanvasContext类的成员函数draw的执行过程如下所示:

           1. 获得应用程序窗口要更新的脏区域之后,调用成员变量mCanvas指向的一个OpenGLRenderer对象的成员函数prepareDirty或者prepare执行一些初始化工作,取决于脏区域是不是空的。

           2, 调用成员变量mCanvas指向的一个OpenGLRenderer对象的成员函数drawRenderNode渲染成员变量mRootRenderNode描述的应用程序窗口的Root Render Node的Display List。

           3. 调用成员变量mCanvas指向的一个OpenGLRenderer对象的成员函数finish执行一些清理工作。在这一步中,如果开启了OverDraw,那么还会在应用程序窗口的上面绘制一些描述OverDraw的颜色块。

           4. 调用另外一个成员函数swapBuffers将前面已经绘制好的图形缓冲区提交给Surface Flinger合成和显示。

           在上述四个步骤中,最重要的是第1步和第2步,因此接下来我们就分别对它们进行分析。

           我们假设第1步得到的应用程序窗口要更新的脏区域不为空,因此这一步执行的就是OpenGLRenderer类的成员函数prepareDirty,它的实现如下所示:

    status_t OpenGLRenderer::prepareDirty(float left, float top,
            float right, float bottom, bool opaque) {
    
        setupFrameState(left, top, right, bottom, opaque);
    
        ......
        if (currentSnapshot()->fbo == 0) {
            ......
            updateLayers();
        } else {
            return startFrame();
        }
    
        return DrawGlInfo::kStatusDone;
    }
           这个函数定义在文件frameworks/base/libs/hwui/OpenGLRenderer.cpp中。

           OpenGLRenderer类的成员函数prepareDirty首先是调用另外一个成员函数setupFrameState设置帧状态,它的实现如下所示:

    void OpenGLRenderer::setupFrameState(float left, float top,
            float right, float bottom, bool opaque) {
        ......
        initializeSaveStack(left, top, right, bottom, mLightCenter);
        ......
    }
           这个函数定义在文件frameworks/base/libs/hwui/OpenGLRenderer.cpp中。

           OpenGLRenderer类的成员函数setupFrameState最主要的操作是调用另外一个成员函数initializeSaveStack初始化一个Save Stack。

           OpenGLRenderer类的成员函数initializeSaveStack是从父类StatefulBaseRenderer继承下来的,它的实现如下所示:

    void StatefulBaseRenderer::initializeSaveStack(float clipLeft, float clipTop,
            float clipRight, float clipBottom, const Vector3& lightCenter) {
        mSnapshot = new Snapshot(mFirstSnapshot,
                SkCanvas::kMatrix_SaveFlag | SkCanvas::kClip_SaveFlag);
        mSnapshot->setClip(clipLeft, clipTop, clipRight, clipBottom);
        mSnapshot->fbo = getTargetFbo();
        mSnapshot->setRelativeLightCenter(lightCenter);
        mSaveCount = 1;
    }
           这个函数定义在文件frameworks/base/libs/hwui/StatefulBaseRenderer.cpp中。

           StatefulBaseRenderer类内部维护有一个Save Stack。这个Save Stack由一系列的Snapshot组成,其中最顶端的Snapshot,也就是当前使用的Snapshot,保存成员变量mSnapshot中。每一个Snapshot都是用来描述当前的一个渲染状态,例如偏移位置、裁剪区间、灯光位置等。 

           Snapshot有一个重要的成员变量fbo。当它的值大于0的时候,就表示要将UI渲染在一个FBO上。涉及到渲染UI的Renderer有两个,一个是LayerRenderer,另外一个是OpenGLRenderer。从前面的分析可以知道,LayerRenderer主要负责用来渲染类型为LAYER_TYPE_HARDWARE的View。这些View将会渲染在一个FBO上。OpenGLRenderer负责渲染应用程序窗口的Display List。这个Display List是直接渲染在Frame Buffer上的,也就是直接渲染在从Surface Flinger请求回来的图形缓冲区上。

          LayerRenderer类继承于OpenGLRenderer类,OpenGLRenderer类又继承于StatefulBaseRenderer类。StatefulBaseRenderer类的成员函数getTargetFbo是一个虚函数,LayerRenderer类和OpenGLRenderer类都重写了它。

          其中,OpenGLRenderer类的成员函数getTargetFbo的实现如下所示:

    class OpenGLRenderer : public StatefulBaseRenderer {
        ......
    
        virtual GLuint getTargetFbo() const {
            return 0;
        }
    
        ......
    }
           这个函数定义在文件frameworks/base/libs/hwui/OpenGLRenderer.h。

           从这里就可以看到,OpenGLRenderer类的成员函数getTargetFbo的返回值总是0,也就是说,OpenGLRenderer类总是直接将UI渲染在Frame Buffer上。

           LayerRenderer类的成员函数getTargetFbo的实现如下所示:

    GLuint LayerRenderer::getTargetFbo() const {
        return mLayer->getFbo();
    }
           这个函数定义在文件frameworks/base/libs/hwui/LayerRenderer.cpp。

           LayerRenderer类的成员变量mLayer描述的是一个Layer对象。这个Layer对象关联有一个FBO对象,可以通过调用它的成员函数getFbo获得。获得FBO被LayerRenderer类的成员函数getTargetFbo返回给调用者。

           回到前面分析的StatefulBaseRenderer类的成员函数initializeSaveStack中,从前面的调用过程可以知道,当前正在处理的是一个OpenGLRenderer对象,因此,成员变量mSnapshot指向的一个Snapshot对象的成员变量fbo的值等于0。

           StatefulBaseRenderer类的成员函数initializeSaveStack执行完成后,回到OpenGLRenderer类的成员函数prepareDirty中,它调用另外一个成员函数currentSnapshot获得的就是父类StatefulBaseRenderer的成员变量mSnapshot描述的Snapshot对象。这个Snapshot对象的成员变量fbo的值是等于0的,因此接下来就会继续调用OpenGLRenderer类的成员函数updateLayers更新那些待更析的Layer对象。

           另一方面,如果当前正在处理的是一个LayerRenderer对象,那么OpenGLRenderer类的成员函数prepareDirty调用的是另外一个成员函数startFrame执行一些Open GL初始化工作,例如设置View Port等基本操作。

           由于当前正在处理的是一个OpenGLRenderer对象,因此我们接下来继续分析OpenGLRenderer类的成员函数updateLayers的实现,如下所示:

    void OpenGLRenderer::updateLayers() {
        ......
        int count = mLayerUpdates.size();
        if (count > 0) {
            ......
    
            for (int i = 0; i < count; i++) {
                Layer* layer = mLayerUpdates.itemAt(i);
                updateLayer(layer, false);
                ......
            }
    
            ......
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/OpenGLRenderer.cpp中。

           前面提到,OpenGLRenderer类的成员变量mLayerUpdates描述的一个Vector保存的都是那些需要更新的Layer对象。每一个Layer对象的更新是通过调用OpenGLRenderer类的另外一个成员函数updateLayer实现的。

           OpenGLRenderer类的成员函数updateLayer的实现如下所示:

    bool OpenGLRenderer::updateLayer(Layer* layer, bool inFrame) {
        if (layer->deferredUpdateScheduled && layer->renderer
                && layer->renderNode.get() && layer->renderNode->isRenderable()) {
            ......
    
            if (CC_UNLIKELY(inFrame || mCaches.drawDeferDisabled)) {
                layer->render(*this);
            } else {
                layer->defer(*this);
            }
    
            ......
    
            return true;
        }
    
        return false;
    }
           这个函数定义在文件frameworks/base/libs/hwui/OpenGLRenderer.cpp中。

           从前面的分析可以知道,保存在OpenGLRenderer类的成员变量mLayerUpdates描述的一个Vector中的Layer对象,它的成员变量deferredUpdateScheduled的值是等于true的。当这些Layer对象设置有自己的Renderer,以及关联有Render Node,并且这个Render Node是可渲染的时候,就会调用它们的成员函数render进行直接更新,或者调用它们的成员函数defer进行延迟更新。

           当参数inFrame的值等于true,或者OpenGLRenderer类的成员变量mCaches指向的一个Caches对象的成员变量drawDeferDisabled的值等于true时,就会调用Layer类的成员函数render进行直接更新。其中,Caches类的成员变量drawDeferDisabled用来描述是否要对Open GL操作进行合并。当它的值等于true时,就表示不要合并;否则就表示需要合并。关于Open GL操作的合并,我们在前面Android应用程序UI硬件加速渲染的预加载资源地图集服务(Asset Atlas Service)分析一文中有提到。

           我们假设Open GL操作需要进行合并,即OpenGLRenderer类的成员变量mCaches指向的一个Caches对象的成员变量drawDeferDisabled等于false。从前面的调用过程可以知道,参数inFrame的值也是等于false,因此接下来OpenGLRenderer类的成员函数updateLayer就会调用Layer类的成员函数defer对参数layer描述的一个Layer对象进行更新。

           Layer类的成员函数defer的实现如下所示:

    void Layer::defer(const OpenGLRenderer& rootRenderer) {
        ......
    
        delete deferredList;
        deferredList = new DeferredDisplayList(dirtyRect);
    
        DeferStateStruct deferredState(*deferredList, *renderer,
                RenderNode::kReplayFlag_ClipChildren);
    
        ......
    
        renderNode->computeOrdering();
        renderNode->defer(deferredState, 0);
    
        deferredUpdateScheduled = false;
    }
           这个函数定义在文件frameworks/base/libs/hwui/Layer.cpp中。

           Layer类的成员函数defer的主要工作是创建一个DeferredDisplayList对象,保存在成员变量deferredList中,然后再将该DeferredDisplayList对象封装成一个DeferStateStruct对象中。同时被封装成这个DeferStateStruct对象还有Layer类的成员变量renderer描述的一个LayerRenderer对象。

           Layer类的成员变量renderNode描述的是当前正在处理的Layer对象所关联的Render Node。Layer类的成员函数defer接下来就分别调用这个Render Node的成员函数computeOrdering和defer。其中,调用Render Node的成员函数defer的时候,会将前面创建的DeferStateStruct对象作为参数传递进去。

           调用一个Render Node的成员函数computeOrdering,是为了找出那些需要投影到它的Background进行渲染的子Render Node。这些子Render Node称为Projected Node,如下所示:

    图3 Projection Nodes

           Projection Node的解释可以参考前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文,RenderNode类的成员函数computeOrdering的实现我们也留给读者自己去分析。最终如果一个Rende Node具有Projected Node,那么这些Projected Node就会保存在它的成员变量mProjectedNodes中。

           回到前面分析的Layer类的成员函数defer中,接下来它要调用的是RenderNode类的成员函数defer,它的实现如下所示:

    void RenderNode::defer(DeferStateStruct& deferStruct, const int level) {
        DeferOperationHandler handler(deferStruct, level);
        issueOperations<DeferOperationHandler>(deferStruct.mRenderer, handler);
    }

           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           RenderNode类的成员函数defer调用另外一个成员函数issueOperations对当前正在处理的Render Node的Display List的绘制命令进行处理,具体的处理是由第二个参数指定的一个DeferOperationHandler对象的操作符重载函数()执行的,如下所示:

    class DeferOperationHandler {
    public:
        DeferOperationHandler(DeferStateStruct& deferStruct, int level)
            : mDeferStruct(deferStruct), mLevel(level) {}
        inline void operator()(DisplayListOp* operation, int saveCount, bool clipToBounds) {
            operation->defer(mDeferStruct, saveCount, mLevel, clipToBounds);
        }
        ......
    private:
        DeferStateStruct& mDeferStruct;
        const int mLevel;
    };
           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           参数operation指向的就是当前正在处理的Render Node的Display List的一个绘制命令,这里调用它的成员函数defer执行我们在前面Android应用程序UI硬件加速渲染的预加载资源地图集服务(Asset Atlas Service)分析一文提到的绘制命令合并操作。

           接下来,我们首先分析RenderNode类的成员函数issueOperations,然后再分析一个典型的DisplayListOp的成员函数defer的实现。

           RenderNode类的成员函数issueOperations的实现如下所示:

    template <class T>
    void RenderNode::issueOperations(OpenGLRenderer& renderer, T& handler) {
        ......
    
        const bool drawLayer = (mLayer && (&renderer != mLayer->renderer));
        ......
    
        bool quickRejected = properties().getClipToBounds()
                && renderer.quickRejectConservative(0, 0, properties().getWidth(), properties().getHeight());
        if (!quickRejected) {
            ......
    
            if (drawLayer) {
                handler(new (alloc) DrawLayerOp(mLayer, 0, 0),
                        renderer.getSaveCount() - 1, properties().getClipToBounds());
            } else {
                ......
                for (size_t chunkIndex = 0; chunkIndex < mDisplayListData->getChunks().size(); chunkIndex++) {
                    const DisplayListData::Chunk& chunk = mDisplayListData->getChunks()[chunkIndex];
    
                    Vector<ZDrawRenderNodeOpPair> zTranslatedNodes;
                    buildZSortedChildList(chunk, zTranslatedNodes);
    
                    issueOperationsOf3dChildren(kNegativeZChildren,
                            initialTransform, zTranslatedNodes, renderer, handler);
    
    
                    for (int opIndex = chunk.beginOpIndex; opIndex < chunk.endOpIndex; opIndex++) {
                        DisplayListOp *op = mDisplayListData->displayListOps[opIndex];
                        ......
                        handler(op, saveCountOffset, properties().getClipToBounds());
    
                        if (CC_UNLIKELY(!mProjectedNodes.isEmpty() && opIndex == projectionReceiveIndex)) {
                            issueOperationsOfProjectedChildren(renderer, handler);
                        }
                    }
    
                    issueOperationsOf3dChildren(kPositiveZChildren,
                            initialTransform, zTranslatedNodes, renderer, handler);
                }
            }
        }
    
        ......
    }
           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           RenderNode类的成员函数issueOperations执行的操作就是对当前正在处理的Render Node的Display List的绘制命令进行重排。为什么需要重排呢?在前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文中,我们分析Display List的结构,如图4所示:

    图4 Display List
           Display List的绘制命令以Chunk为单位进行保存。每一个Chunk通过begin op index和end op index描述的一系列Display List Op对应的就是一个Render Node包含绘制命令。此外,每一个Chunk还通过begin child index和end child index描述的一系列Draw Render Node Op对应的就是一个Render Node的子Render Node相关的绘制命令。这些子Render Node的Z轴位置相对父Render Node有可能是负的,也有可能是正的。对于Z轴位置为负的子Render Node的绘制命令,它们应该先于父Render Node的绘制命令执行。而对于Z轴位置为正的子Render Node的绘制命令,它们应该后于父Render Node的绘制命令执行。因此,每一个Chunk描述的绘制命令的排列顺序就如下所示:

           1. Z轴位置为负的子Render Node的绘制命令。

           2. 父Render Node的绘制命令。

           3. Z轴位置为正的子Render Node的绘制命令。

           此外,如果一个Render Node的的某一个Display List Op恰好是一个图3所示的Projection Receiver,那么还需要Render Node的所有Projected Node的绘制命令排列在该Projection Receiver的后面。

           如果一个Render Node设置了Layer,那么就意味着这个Render Node的所有绘制命令都是作为一个整体进行执行的。也就是说,对于设置了Layer的Render Node,我们首先需要将它的Display List的所有绘制命令合成一个整体的绘制命令,目的就是为了得到一个FBO,然后渲染这个FBO就可以得一个Render Node的UI。

           对于设置了Layer的Render Node来说,它的成员函数defer会被调用两次。第一次调用的时候,就是为了将它的Display List的所有绘制命令合成一个FBO。第二次调用的时候,就是为了将合成后的FBO渲染到应用程序窗口的UI上。

           这时候RenderNode类的成员函数defer属于第一次执行。那么RenderNode类的成员函数issueOperations是如何区分它是被第一次调用的成员函数defer调用,还是第二次调用的成员函数defer调用呢?主要是通过比较参数renderer描述的OpenGLRender对象和成员变量mLayer指向的一个Layer对象的成员变量renderer描述折一个OpenGLRender对象来区分。如果这两个OpenGLRenderer对象是同一个,就意味着是被第一次调用的成员函数defer调用;否则的话,就是被第二次调用的成员函数defer调用。

           当RenderNode类的成员函数issueOperations是被第二次调用的成员函数defer调用的时候,该Render Node的Display List的所有绘制命令已经被合成在一个FBO里面,并且这个FBO是由它所关联的Layer对象维护的,因此这时候只需要将该Layer对象封装成一个DrawLayerOp交给参数handler描述的一个DeferOperationHandler对象处理即可。

           我们再确认一下现在RenderNode类的成员函数issueOperations是被第一次调用的成员函数defer调用。它的参数renderer指向的一个OpenGLRenderer对象是从Layer类的成员函数defer传递进行的,而Layer类的成员函数defer传递进行的这个OpenGLRenderer对象就正好是与Render Node关联的Layer对象的成员变量renderer描述折一个OpenGLRender对象,因此它们就是相同的。从前面的分析可以知道,这个OpenGLRenderer对象的实际类型是LayerRenderer。

           后面我们会看到,当Render Node的成员函数issueOperations是被第二次调用的成员函数defer调用的时候,它的参数renderer指向的一个OpenGLRenderer对象的实际类型就是OpenGLRenderer,它与当前正在处理的Render Node关联的Layer对象的成员变量描述折一个OpenGLRender对象不可能是相同的,因为后者的实际类型是LayerRenderer。

           接下来我们就继续分析RenderNode类的成员函数issueOperations是被第一次调用的成员函数defer调用时的执行情况,这时候得到的本地变量drawLayer的值为false。

           RenderNode类的成员函数issueOperations首先是判断当前正在处理的Render Node的占据的屏幕位置在应用程序窗口的当前帧中是否是可见的。如果不可见,那么得到的本地变量quickRejected的值就等于true。在这种情况下就不用做任何事情。

          当本地变量quickRejected的值就等于false,并且本地变量drawLayer的值也等于false的时候,RenderNode类的成员函数issueOperations就对当前正在处理的Render Node的Display List的所有绘制命令按照我们上面描述的规则进行排序。

           RenderNode类的成员函数issueOperations通过一个for循环对当前正在处理的Render Node的Display List的绘制命令按Chunk进行处理。对于每一个Chunk:

           1. 调用成员函数buildZSortedChildList对其子Render Node相关的Draw Render Node Op按照Z轴位置从小到大的顺序排列在本地变量zTranslatedNodes描述的一个Vector中。

           2. 调用成员函数issueOperationsOf3dChildren将Z轴位置为负的子Render Node相关的Draw Render Node Op交给参数handler描述的一个DeferOperationHandler对象处理。

           3. 通过一个for循环依次将当前正在处理的Render Node相关的Display List Op交给参数handler描述的一个DeferOperationHandler对象处理。如果其中的某一个Display List Op是一个Projection Receiver,那么就继续调用成员函数issueOperationsOfProjectedChildren将当前正在处理的Render Node的Projected Node交给参数handler描述的一个DeferOperationHandler对象处理。

           4. 调用成员函数issueOperationsOf3dChildren将Z轴位置为正的子Render Node相关的Draw Render Node Op交给参数handler描述的一个DeferOperationHandler对象处理。

           接下来我们继续分析RenderNode类的成员函数issueOperationsOf3dChildren和issueOperationsOfProjectedChildren的实现。

           RenderNode类的成员函数issueOperationsOf3dChildren的实现如下所示:

    template <class T>
    void RenderNode::issueOperationsOf3dChildren(ChildrenSelectMode mode,
            const Matrix4& initialTransform, const Vector<ZDrawRenderNodeOpPair>& zTranslatedNodes,
            OpenGLRenderer& renderer, T& handler) {
        const int size = zTranslatedNodes.size();
        ......
    
        const size_t nonNegativeIndex = findNonNegativeIndex(zTranslatedNodes);
        size_t drawIndex, shadowIndex, endIndex;
        if (mode == kNegativeZChildren) {
            drawIndex = 0;
            endIndex = nonNegativeIndex;
            shadowIndex = endIndex; // draw no shadows
        } else {
            drawIndex = nonNegativeIndex;
            endIndex = size;
            shadowIndex = drawIndex; // potentially draw shadow for each pos Z child
        }
    
        ......
    
        while (shadowIndex < endIndex || drawIndex < endIndex) {
           ......
    
            DrawRenderNodeOp* childOp = zTranslatedNodes[drawIndex].value;
            ......
            childOp->mSkipInOrderDraw = false; // this is horrible, I'm so sorry everyone
            handler(childOp, renderer.getSaveCount() - 1, properties().getClipToBounds());
            childOp->mSkipInOrderDraw = true;
            ......
            drawIndex++;
        }
        
        ......
    }
           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           RenderNode类的成员函数issueOperationsOf3dChildren既用来处理Z轴位置为负的子Render Node相关的Draw Render Node Op,也用来处理Z轴位置为正的子Render Node相关的Draw Render Node Op,因此它就需要根据参数mode以及参数zTranslatedNodes描述的一个Vector中Z轴位置为非负的子Render Node相关的Draw Render Node Op的索引nonNegativeIndex来确定当前需要处理的子Render Node相关的Draw Render Node Op。

           由于参数zTranslatedNodes描述的一个Vector中的Draw Render Node Op是按照它们对应的子Render Node的Z轴位置由小到大的顺序排列的,因此如果参数mode的值等于kNegativeZChildren,那么当前需要处理的Draw Render Node Op在参数zTranslatedNodes描述的一个Vector中的索引范围就为[0, nonNegativeIndex)。另一方面,如果参数mode的值等于kPositiveZChildren,,那么当前需要处理的Draw Render Node Op在参数zTranslatedNodes描述的一个Vector中的索引范围就为[nonNegativeIndex, size),其中,size为参数zTranslatedNodes描述的一个Vector的大小。

           确定了要处理的Draw Render Node Op在参数zTranslatedNodes描述的一个Vector的范围之后,就可以通过一个while循环对它们进行处理了,处理的方式就将它们交给参数handler描述的一个DeferOperationHandler对象。

           在将要处理的Draw Render Node Op交给参数handler描述的一个DeferOperationHandler对象处理之前,有一个小Hack,这些Draw Render Node Op的成员变量mSkipInOrderDraw的值设置为false,处理完成之后再恢复为true。这样做的目的是为了当前正在处理的Render Node以相同的方式递归处理其子Render Node的Display List的绘制命令。我们在后面将会看到这一点。

           我们再来看RenderNode类的成员函数issueOperationsOfProjectedChildren的实现,如下所示:

    template <class T>
    void RenderNode::issueOperationsOfProjectedChildren(OpenGLRenderer& renderer, T& handler) {
        ......
    
        // draw projected nodes
        for (size_t i = 0; i < mProjectedNodes.size(); i++) {
            DrawRenderNodeOp* childOp = mProjectedNodes[i];
            ......
            childOp->mSkipInOrderDraw = false; // this is horrible, I'm so sorry everyone
            handler(childOp, renderer.getSaveCount() - 1, properties().getClipToBounds());
            childOp->mSkipInOrderDraw = true; 
            ......
        }
    
        ......
    }
           这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

           RenderNode类的成员函数issueOperationsOfProjectedChildren主要就是将成员变量mProjectedNodes描述的一个Vector中的所有Draw Render Node Op都交给参数handler描述的一个DeferOperationHandler对象处理。其中,RenderNode类的成员变量mProjectedNodes描述的一个Vector应该包含哪些Projected Node就是在Layer类的成员函数defer中调用当前正在处理的Render Node的成员函数computeOrdering来计算得到的。

           同样,在将要处理的Draw Render Node Op交给参数handler描述的一个DeferOperationHandler对象处理之前,这些Draw Render Node Op的成员变量mSkipInOrderDraw的值设置为false,处理完成之后再恢复为true。这样做的目的是为了当前正在处理的Render Node以相同的方式递归处理它的Projected Node的Display List的绘制命令。我们在后面将会看到这一点。

           这一步执行完成之后,回到RenderNode类的成员函数issueOperations中,现在当前正在处理的Render Node的Display List的所有绘制命令都按照我们前面描述的顺序交给参数handler描述的一个DeferOperationHandler对象处理了,也就是调用该DeferOperationHandler对象的操作符重载函数()进行处理。以一个类型为DrawOp的Display List Op为例,DeferOperationHandler对象的操作符重载函数()会调用它的成员函数defer进行处理。

           DrawOp类的成员函数defer的实现如下所示:

    class DrawOp : public DisplayListOp {
        ......
    
        virtual void defer(DeferStateStruct& deferStruct, int saveCount, int level,
                bool useQuickReject) {
            ......
    
            deferStruct.mDeferredList.addDrawOp(deferStruct.mRenderer, this);
        }
    
        ......
    };
           这个函数定义在文件frameworks/base/libs/hwui/DisplayListOp.h中。

           DrawOp类的成员函数defer调用了参数deferStruct描述的一个DeferStateStruct对象的成员变量mDeferredList指向的一个DeferredDisplayList对象的成员函数addDrawOp检查当前正在处理的一个DrawOp是否可以与其它DrawOp进行合并,它的实现如下所示:

    void DeferredDisplayList::addDrawOp(OpenGLRenderer& renderer, DrawOp* op) {
        /* 1: op calculates local bounds */
        DeferredDisplayState* const state = createState();
        if (op->getLocalBounds(state->mBounds)) {
            if (state->mBounds.isEmpty()) {
                .......
                return;
            }
        } else {
            state->mBounds.setEmpty();
        }
    
        /* 2: renderer calculates global bounds + stores state */
        if (renderer.storeDisplayState(*state, getDrawOpDeferFlags())) {
            ......
            return; // quick rejected
        }
    
        /* 3: ask op for defer info, given renderer state */
        DeferInfo deferInfo;
        op->onDefer(renderer, deferInfo, *state);
    
        // complex clip has a complex set of expectations on the renderer state - for now, avoid taking
        // the merge path in those cases
        deferInfo.mergeable &= !recordingComplexClip();
        deferInfo.opaqueOverBounds &= !recordingComplexClip() && mSaveStack.isEmpty();
    
        if (CC_LIKELY(mAvoidOverdraw) && mBatches.size() &&
                state->mClipSideFlags != kClipSide_ConservativeFull &&
                deferInfo.opaqueOverBounds && state->mBounds.contains(mBounds)) {
            // avoid overdraw by resetting drawing state + discarding drawing ops
            discardDrawingBatches(mBatches.size() - 1);
            ......
        }
    
        if (CC_UNLIKELY(renderer.getCaches().drawReorderDisabled)) {
            // TODO: elegant way to reuse batches?
            DrawBatch* b = new DrawBatch(deferInfo);
            b->add(op, state, deferInfo.opaqueOverBounds);
            mBatches.add(b);
            return;
        }
    
        // find the latest batch of the new op's type, and try to merge the new op into it
        DrawBatch* targetBatch = NULL;
    
        // insertion point of a new batch, will hopefully be immediately after similar batch
        // (eventually, should be similar shader)
        int insertBatchIndex = mBatches.size();
        if (!mBatches.isEmpty()) {
            if (state->mBounds.isEmpty()) {
                // don't know the bounds for op, so add to last batch and start from scratch on next op
                DrawBatch* b = new DrawBatch(deferInfo);
                b->add(op, state, deferInfo.opaqueOverBounds);
                mBatches.add(b);
                ......
                return;
            }
    
            if (deferInfo.mergeable) {
                // Try to merge with any existing batch with same mergeId.
                if (mMergingBatches[deferInfo.batchId].get(deferInfo.mergeId, targetBatch)) {
                    if (!((MergingDrawBatch*) targetBatch)->canMergeWith(op, state)) {
                        targetBatch = NULL;
                    }
                }
            } else {
                // join with similar, non-merging batch
                targetBatch = (DrawBatch*)mBatchLookup[deferInfo.batchId];
            }
    
            if (targetBatch || deferInfo.mergeable) {
                // iterate back toward target to see if anything drawn since should overlap the new op
                // if no target, merging ops still interate to find similar batch to insert after
                for (int i = mBatches.size() - 1; i >= mEarliestBatchIndex; i--) {
                    DrawBatch* overBatch = (DrawBatch*)mBatches[i];
    
                    if (overBatch == targetBatch) break;
    
                    // TODO: also consider shader shared between batch types
                    if (deferInfo.batchId == overBatch->getBatchId()) {
                        insertBatchIndex = i + 1;
                        if (!targetBatch) break; // found insert position, quit
                    }
    
                    if (overBatch->intersects(state->mBounds)) {
                        // NOTE: it may be possible to optimize for special cases where two operations
                        // of the same batch/paint could swap order, such as with a non-mergeable
                        // (clipped) and a mergeable text operation
                        targetBatch = NULL;
                        ......
                        break;
                    }
                }
            }
        }
    
        if (!targetBatch) {
            if (deferInfo.mergeable) {
                targetBatch = new MergingDrawBatch(deferInfo,
                        renderer.getViewportWidth(), renderer.getViewportHeight());
                mMergingBatches[deferInfo.batchId].put(deferInfo.mergeId, targetBatch);
            } else {
                targetBatch = new DrawBatch(deferInfo);
                mBatchLookup[deferInfo.batchId] = targetBatch;
            }
    
            ......
            mBatches.insertAt(targetBatch, insertBatchIndex);
        }
    
        targetBatch->add(op, state, deferInfo.opaqueOverBounds);
    }

           这个函数定义在文件frameworks/base/libs/hwui/DeferredDisplayList.cpp中。

           在分析DeferredDisplayList类的成员函数addDrawOp的实现之前,我们首先要了解它的三个成员变量mBatches、mBatchLookup和mMergingBatches,如下所示:

    class DeferredDisplayList {
        friend class DeferStateStruct; // used to give access to allocator
    public:
        ......
    
        enum OpBatchId {
            kOpBatch_None = 0, // Don't batch
            kOpBatch_Bitmap,
            kOpBatch_Patch,
            kOpBatch_AlphaVertices,
            kOpBatch_Vertices,
            kOpBatch_AlphaMaskTexture,
            kOpBatch_Text,
            kOpBatch_ColorText,
    
            kOpBatch_Count, // Add other batch ids before this
        };
    
        ......
    private:
        ......
    
        Vector<Batch*> mBatches;
    
        // Maps batch ids to the most recent *non-merging* batch of that id
        Batch* mBatchLookup[kOpBatch_Count];
        ......
    
        /**
         * Maps the mergeid_t returned by an op's getMergeId() to the most recently seen
         * MergingDrawBatch of that id. These ids are unique per draw type and guaranteed to not
         * collide, which avoids the need to resolve mergeid collisions.
         */
        TinyHashMap<mergeid_t, DrawBatch*> mMergingBatches[kOpBatch_Count];
      
        ......
    };

           这三个成员变量定义在文件frameworks/base/libs/hwui/DeferredDisplayList.h中。

           可以批量进行处理的绘制命令,也就是DrawOp,放在同一个Batch中,这些Batch按照绘制先后顺序保存在DeferredDisplayList类的成员变量mBatches描述的一个Vector中。注意,这里说的批量处理,有两种含义。第一种含义是在同一个Batch中的每一个DrawOp都是单独执行的,不过它们是按顺序执行的。第二种含义是在在同一个Batch中的所有DrawOp都是一次性执行的。其中,第二种含义才称为合并执行。

           两个DrawOp可以合并执行的必要条件是它们具有相同的Batch ID和Merge ID。注意,这不是充分条件。也就是说,具有相同Batch ID和Merge ID的两个Draw Op不一定能够合并执行。例如,当它们重叠,或者在它们之间存在另外的DrawOp与它们重叠。这些都会造成两个具有相同Batch ID和Merge ID的Draw Op不能合并执行。

           对于具有相同Batch ID但是不同的Merge ID的两个Draw Op,我们希望它们将放在相邻的位置,因为Batch ID描述的是一种绘制类型。这些绘制类型由枚举类型OpBatchId定义。这样GPU在执行这些Draw Op时,在内部就不需要进行状态切换,这样可以提高效率。当然,也并不是所有具有相同Batch ID的DrawOp都能够放在相邻的位置,因为它们之间可能存在其它的Draw Op与它们重叠。

           基于以上的分析,当给出一个DrawOp时,我们希望:

           1. 在DeferredDisplayList类的成员变量mBatches描述的一个Vector中快速找可以与它进行合并执行的DrawOp所在的Batch。这时候就需要用到DeferredDisplayList类的成员变量mMergingBatches描述的是一个TinyHashMap数组了。这个数组的大小为kOpBatch_Count,这意味着每一个Batch ID在这个数组中都有一个TinyHashMap。因此,给出一个DrawOp,我们根据它的Batch ID就可以快速得到一个TinyHashMap。有了这个TinyHashMap,我们再以给出的Draw Op的Merge ID作为键值,快速找到一个Batch。接着再根据其它条件判断给出的DrawOp与在找到的Batch中已经存在的DrawOp是否能够合并。如果能够合并,就将给出的DrawOp添加到找到的Batch去就行了。

           2. 如果不能在DeferredDisplayList类的成员变量mBatches描述的一个Vector中可以让它合并的Batch时,我们希望可以快速找到另外一个Batch,这个Batch的所有DrawOp都是依次地单独执行。这时候就需要用到DeferredDisplayList类的成员变量mBatchLookup描述的一个Batch数组了。这个数组的大小同样为kOpBatch_Count,这也意味着每一个Batch ID在这个数组中都有一个Batch。因此,给出一个DrawOp,我们根据它的Batch ID就可以快速得到一个Batch。接着再根据其它条件判断给出的DrawOp与在找到的Batch中已经存在的DrawOp是否能够合并。如果能够合并,就将给出的DrawOp添加到找到的Batch去就行了。

           3. 如果通过上面的两个方法还是不能找到一个Batch,那么就需要创建一个新的Batch来存放给出的Draw Op。但是我们希望可以将这个新创建的Batch放在与它具有相同Batch ID的Batch相邻的位置上。

           了解了DeferredDisplayList类的三个成员变量mBatches、mBatchLookup和mMergingBatches的作用之后,我们再来看另外一个结构体DeferInfo,如下所示:

    struct DeferInfo {
    public:
        DeferInfo() :
                batchId(DeferredDisplayList::kOpBatch_None),
                mergeId((mergeid_t) -1),
                mergeable(false),
                opaqueOverBounds(false) {
        };
    
        int batchId;
        mergeid_t mergeId;
        bool mergeable;
        bool opaqueOverBounds; // opaque over bounds in DeferredDisplayState - can skip ops below
    };

           这个结构体定义在文件frameworks/base/libs/hwui/DeferredDisplayList.h中。

           结构体DeferInfo有四个成员变量,分别是:

           1. batchId:描述一个DrawOp的Batch ID。

           2. mergeId:描述一个DrawOp的Merge ID。

           3. mergeable:描述一个DrawOp是否具有与其它DrawOp进行合并的条件,最终能不能合并还要取决于其它条件。

           4. opaqueOverBounds:描述的一个DrawOp是不是不透明绘制。如果是的话,就会可能覆盖在它前面的DrawOp,但是最终能不能覆盖同样还要取决于其它条件。

           每一个DrawOp都定义有一个成员函数onDefer,用来设置一个DeferInfo结构体的各个成员变量,以便调用者可以知道它的Batch ID和Merge ID,以及它的合并和覆盖绘制信息。具体的例子可以参考前面Android应用程序UI硬件加速渲染的预加载资源地图集服务(Asset Atlas Service)分析一文。

           有了上面这些知识之后,我们就开始分析上面列出的DrawOp类的成员函数defer的代码。为了描述分便,我们分段来阅读:

        /* 1: op calculates local bounds */
        DeferredDisplayState* const state = createState();
        if (op->getLocalBounds(state->mBounds)) {
            if (state->mBounds.isEmpty()) {
                .......
                return;
            }
        } else {
            state->mBounds.setEmpty();
        }
           这段代码是获得参数op描述的DrawOp的绘制区域,保存在本地变量state指向的一个DeferDisplayState结构体的成员变量mBounds中。通过调用这个DrawOp的成员函数getLocalBounds可以获得它的绘制区域。

           如果这个DrawOp设置了一个空区域,那么就不会对它进行处理了。另一方面,如果这个DrawOp没有设置绘制区载,调用它的成员函数getLocalBounds得到的返回值为false,这时候会将本地变量const_state指向的一个DeferDisplayState结构体的成员变量mBounds描述的区域设置为空,但是其实想表达的意思是未设置绘制区域。

        /* 2: renderer calculates global bounds + stores state */
        if (renderer.storeDisplayState(*state, getDrawOpDeferFlags())) {
            ......
            return; // quick rejected
        }

           这段代码调用参数renderer描述的一个OpenGLRender对象的成员函数storeDisplayState设置参数op描述的DrawOp的裁剪区域。如果参数op描述的DrawOp描述的绘制区域与当前的裁剪区域没有交集,那么就说明该DrawOp是不可见的,因此就不用对它进行绘制了,于是就不用往下处理了。       

        /* 3: ask op for defer info, given renderer state */
        DeferInfo deferInfo;
        op->onDefer(renderer, deferInfo, *state);
    
        // complex clip has a complex set of expectations on the renderer state - for now, avoid taking
        // the merge path in those cases
        deferInfo.mergeable &= !recordingComplexClip();
        deferInfo.opaqueOverBounds &= !recordingComplexClip() && mSaveStack.isEmpty();
    

           这段代码调用参数op描述的DrawOp获得一个初始好的DeferInfo结构体,也就是获得参数op描述的DrawOp的Batch ID和Merge ID,以及合并和覆盖绘制信息。

           如果参数op描述的DrawOp表明自己可以与其它具有相同Batch ID和Merge ID的DrawOp合并,但是如果当前的裁剪区域是一个复杂的裁剪区域,也就是由一系列正则的矩形组合形成的复杂区域,那么就会禁止op描述的DrawOp与其它具有相同Batch ID和Merge ID的DrawOp合并。

           同样,如果参数op描述的DrawOp表明自己的绘制会覆盖前面的DrawOp,但是如果当前的裁剪区域是一个复杂的裁剪区域,或者当前是绘制在一个Layer上,那么就会禁止op描述的DrawOp覆盖前面的DrawOp。

           复杂的裁剪区域会导致具有相同Batch ID和Merge ID的DrawOp不能正确地合并,同时也会导致不透明的DrawOp不能正确地覆盖前面的DrawOp。另外,如果参数op描述的DrawOp是绘制在一个Layer之上,也就是在它之前有一个saveLayer操作,该操作会创建一个Layer,那么后面会有一个对应的restore/restoreToCount操作。当执行restore/restoreToCount操作的时候,前面绘制出来的Layer会被合并在前一个Layer或者Frame Buffer之上。这个合并的操作导致参数op描述的DrawOp不能直接就覆盖前面的DrawOp,也就是丢弃前面的DrawOp。

        if (CC_LIKELY(mAvoidOverdraw) && mBatches.size() &&
                state->mClipSideFlags != kClipSide_ConservativeFull &&
                deferInfo.opaqueOverBounds && state->mBounds.contains(mBounds)) {
            // avoid overdraw by resetting drawing state + discarding drawing ops
            discardDrawingBatches(mBatches.size() - 1);
            ......
        }

           这段代码综合判断参数op描述的DrawOp是否能够覆盖排在前面的DrawOp。如果以下条件都能满足,那么参数op描述的DrawOp是否能够覆盖排在前面的DrawOp:

           1. 当前设置了禁止过度绘制,即DeferredDisplayList类的成员变量mAvoidOverdraw的值等于true。在启用过度绘制的情况下,即使是被覆盖的区域,也要进行绘制。这样才能将看到过度绘制。

           2. 在参数op描述的DrawOp之前,已经存在其它的DrawOp,也就是DeferredDisplayList类的成员变量mBatches描述的一个Vector不为空,这样才有DrawOp被覆盖。

           3. 参数op描述的DrawOp明确设置有绘制区域。如果参数op描述的DrawOp没有设置绘制区域,那么本地变量state指向的一个state指向的一个DeferDisplayState结构体的成员变量mClipSideFlags的值会被设置为kClipSide_ConservativeFull。未设置绘制区域的DrawOp,我们就不能明确地知道它会不会覆盖之前的DrawOp。

           4. 参数op描述的DrawOp表明自己是不透明绘制,即本地变量deferInfo描述的一个DeferInfo结构体的成员变量opaqueOverBounds的值等于ture。

           5. 参数op描述的DrawOp的绘制区域包含了之前的DrawOp合并起来的绘制区域。

           这些排在前面的DrawOp就保存在DeferredDisplayList类的成员变量mBatches描述的一个Vector中。如果能够覆盖,那么就可以丢弃它们,实际上就是调用DeferredDisplayList类的成员函数discardDrawingBatches清空上述Vector。

        if (CC_UNLIKELY(renderer.getCaches().drawReorderDisabled)) {
            // TODO: elegant way to reuse batches?
            DrawBatch* b = new DrawBatch(deferInfo);
            b->add(op, state, deferInfo.opaqueOverBounds);
            mBatches.add(b);
            return;
        }
           如果参数renderer描述的一个OpenGLRenderer表明自己禁止重新排序它的DrawOp,也就是禁止执行DrawOp的合并操作,这时候就会直接为参数op描述的DrawOp创建一个Batch,并且保存在DeferredDisplayList类的成员变量mBatches描述的一个Vector中。这意味着每一个DrawOp都会有独立保存一个Batch中,这样就可以避免出现合并操作。       

        // find the latest batch of the new op's type, and try to merge the new op into it
        DrawBatch* targetBatch = NULL;
    
        // insertion point of a new batch, will hopefully be immediately after similar batch
        // (eventually, should be similar shader)
        int insertBatchIndex = mBatches.size();
        if (!mBatches.isEmpty()) {
            if (state->mBounds.isEmpty()) {
                // don't know the bounds for op, so add to last batch and start from scratch on next op
                DrawBatch* b = new DrawBatch(deferInfo);
                b->add(op, state, deferInfo.opaqueOverBounds);
                mBatches.add(b);
                ......
                return;
            }

           这段代码判断在参籹op描述的DrawOp之前,是否已经存在其它的DrawOp。如果存在,但是参籹op描述的DrawOp又没有设置绘制区域,那么即使前面的DrawOp能够与它进行合并,那么也是禁止的。这时候就单独为它创建一个Batch,并且保存在DeferredDisplayList类的成员变量mBatches描述的一个Vector中。

            if (deferInfo.mergeable) {
                // Try to merge with any existing batch with same mergeId.
                if (mMergingBatches[deferInfo.batchId].get(deferInfo.mergeId, targetBatch)) {
                    if (!((MergingDrawBatch*) targetBatch)->canMergeWith(op, state)) {
                        targetBatch = NULL;
                    }
                }
            } else {
                // join with similar, non-merging batch
                targetBatch = (DrawBatch*)mBatchLookup[deferInfo.batchId];
            }
           如果参数op描述的DrawOp表明自己可以与其它具有相同Batch ID和Merge ID的DrawOp进行合并,那么这段代码就按照我们前面描述的,通过DeferredDisplayList类的成员变量mMergingBatches描述的一个TinyHashMap数组,快速找到一个具有相同Batch ID和Merge ID的Batch。如果能找到这样的Batch,还需要调用这个Batch的成员函数canMergeWith判断已经存在该Batch的DrawOp是否能够真的与参数op描述的DrawOp进行合并。例如,对于Batch ID等于kOpBatch_Text的两个文字绘制DrawOp,如果文字的颜色不一样,那么这两个DrawOp合并。

           如果参数op描述的DrawOp表明自己不可以与其它DrawOp进行合并,那么这段代码也是按照我们前面描述的,通过DeferredDisplayList类的成员变量mBatchLookup描述的一个Batch数组,找到一个与它具有相同的Batch ID的Batch,以便将参数op描述的DrawOp加入到这个Batch去进行依次的独立绘制。

            if (targetBatch || deferInfo.mergeable) {
                // iterate back toward target to see if anything drawn since should overlap the new op
                // if no target, merging ops still interate to find similar batch to insert after
                for (int i = mBatches.size() - 1; i >= mEarliestBatchIndex; i--) {
                    DrawBatch* overBatch = (DrawBatch*)mBatches[i];
    
                    if (overBatch == targetBatch) break;
    
                    // TODO: also consider shader shared between batch types
                    if (deferInfo.batchId == overBatch->getBatchId()) {
                        insertBatchIndex = i + 1;
                        if (!targetBatch) break; // found insert position, quit
                    }
    
                    if (overBatch->intersects(state->mBounds)) {
                        // NOTE: it may be possible to optimize for special cases where two operations
                        // of the same batch/paint could swap order, such as with a non-mergeable
                        // (clipped) and a mergeable text operation
                        targetBatch = NULL;
                        ......
                        break;
                    }
                }
            }
        }
           这段代码判断参数op描述的DrawOp是否真的能加入到前面找到的Batch去,主要就是判断参数op描述的DrawOp与找到的Batch里面的DrawOp之间,是否存在其它的DrawOp与它重叠。如果存在,那么就不能够将参数op描述的DrawOp是否真的能加入到前面找到的Batch去了。这意味着要为参数op描述的DrawOp创建一个独立的Batch。这个Batch也是按照我们前面描述的,尽可能放在前面与它具有相同Batch ID的Batch的相邻位置。这个位置就通过设置本地变量insertBatchIndex的值得到。

        if (!targetBatch) {
            if (deferInfo.mergeable) {
                targetBatch = new MergingDrawBatch(deferInfo,
                        renderer.getViewportWidth(), renderer.getViewportHeight());
                mMergingBatches[deferInfo.batchId].put(deferInfo.mergeId, targetBatch);
            } else {
                targetBatch = new DrawBatch(deferInfo);
                mBatchLookup[deferInfo.batchId] = targetBatch;
            }
    
            ......
            mBatches.insertAt(targetBatch, insertBatchIndex);
        }
    
        targetBatch->add(op, state, deferInfo.opaqueOverBounds);
           这段代码判断本地变量targetBatch的值。如果等于NULL,那么就表明前面不能在DeferredDisplayList类的成员变量mBatches描述的一个Vector中找到一个能够用来保存参数op描述的DrawOp的Batch。这时候就需要为参数op描述的DrawOp创建一个Batch了。这个Batch的具体类型要么是MergingDrawBatch,要么是DrawBatch,取决于参数op描述的DrawOp是否表明自己是可合并的,即本地变量deferInfo描述的一个DeferInfo结构体的成员变量mergeable的值是否为true。

           如果参数op描述的DrawOp表明自己是可合并的,那么就为它创建一个MergingDrawBatch,并且保存在DeferredDisplayList类的成员变量mMergingBatches描述的一个TinyHashMap数组中,使得它后面的与它具有相同Batch ID和Merge ID的DrawOp能够快速找到它。

           如果参数op描述的DrawOp表明自己是不可以合并的,那么就为它创建一个DrawBatch,并且保存在DeferredDisplayList类的成员变量mBatchLookup描述的一个Batch数组中,以便它后面的与它具有相同Batch ID的DrawOp能够快速找到它。

           这意味着保存在同一个MergingDrawBatch的DrawOp,在渲染的时候是可以进合并绘制的,而保存在同一个rawBatch的DrawOp,在渲染的时候是可以连续地进行独立绘制的。

           最后,新创建的Batch就根据前面得到的本地变量insertBatchIndex的值保存在DeferredDisplayList类的成员变量mBatches描述的一个Vector中,使得该Batch尽可能地与它具有同的Batch ID的Batch放在一起。

           另一方面,如果本地变量targetBatch的值不等于NULL,那么就表明前面找到了一个Batch,这个Batch可以用来保存参数op描述的DrawOp。

           这样,当DeferredDisplayList类的成员addDrawOp执行完成之后,当前正在处理的所有DrawOp都经过合并等处理了,并且处理后得到的DrawOp以Batch为单位保存在DeferredDisplayList类的成员变量mBatches描述的一个Vector中。

           上面描述的是一个普通的DrawOp的成员函数defer被调用时所执行的绘制命令重排和合并操作。还有另外一种特殊的Display List Op,即DrawRenderNodeOp。从前面的分析可以知道,当一个Render Node包含有子Render Node时,它的Display List包含有一个对应的DrawRenderNodeOp。此外,当一个Render Node具有Projected Node时,每一个Projected Node都有一个对应的DrawRenderNodeOp保存该Render Node的成员变量mProjectedNodes描述的一个Vector。所有的这些DrawRenderNodeOp也像DrawOp一样,会被DeferOperationHandler类的操作符重载函数()调用它们的成员函数defer。

           DrawRenderNodeOp类的成员函数defer的实现如下所示:

    class DrawRenderNodeOp : public DrawBoundedOp {
        ......
    
        virtual void defer(DeferStateStruct& deferStruct, int saveCount, int level,
                bool useQuickReject) {
            if (mRenderNode->isRenderable() && !mSkipInOrderDraw) {
                mRenderNode->defer(deferStruct, level + 1);
            }
        }
    
        ......
    };
           这个函数定义在文件frameworks/base/libs/hwui/DisplayListOp.h中。

           DrawRenderNodeOp类的成员变量mRenderNode描述的是当前正在处理的DrawRenderNodeOp所关联的一个Render Node。当这个Render Node的Display List不为空时,就表示这个Render Node的Display List的绘制命令需要执行重排和合并操作。

           此外,DrawRenderNodeOp类还有另外一个成员变量mSkipInOrderDraw。当它的值等于true时,就表示当前正在处理的DrawRenderNodeOp所关联的Render Node要跳过顺序绘制。这是什么意思呢?其实这是针对我们前面提到的Ripple Drawable的。我们知道,Ripple Drawable有可能不是按照它们在视图结构的顺序绘制的,因为它们有可能会被投影到最近一个父Render Node的Backround去绘制。这样当它们对应的Render Node在顺序绘制中就应该跳过处理。

           在我们这个情景中,这里的DrawRenderNodeOp类的成员函数defer并不是在顺序绘制过程中被调用的,而是在重排和合并一个Render Node的Display List的绘制命令的过程中调用的,也就是在前面分析的RenderNode类的成员函数issueOperationsOf3dChildren和issueOperationsOfProjectedChildren中调用的。这两个成员函数需要强制DrawRenderNodeOp类的成员函数defer重排和合并当前正在处理的DrawRenderNodeOp所关联的一个Render Node的Display List的绘制命令,因此就会强制当前正在处理的DrawRenderNodeOp的成员变量mSkipInOrderDraw设置为false。

           这样,当一个DrawRenderNodeOp的成员变量mSkipInOrderDraw的值为false,并且它关联的Render Node的Display List不为空,这个Render Node的成员函数defer就会被调用。这意味着通过DrawRenderNodeOp类的成员函数defer,一个Render Node及其所有的子Render Node和Projected Node的Display List的绘制命令都会得到归递重排和合并处理。

           这一步执行完成之后,回到CanvasContext类的成员函数draw中,这时候所有设置了Layer的Render Node的Display List包含的Display List Op都已经得到了重排和合并等处理,接下来要做的事情就是调用OpenGLRenderer类的成员函数drawRenderNode渲染应用程序窗口的Root Render Node的Display List。

           OpenGLRenderer类的成员函数drawRenderNode的实现如下所示:

    status_t OpenGLRenderer::drawRenderNode(RenderNode* renderNode, Rect& dirty, int32_t replayFlags) {
        status_t status;
        // All the usual checks and setup operations (quickReject, setupDraw, etc.)
        // will be performed by the display list itself
        if (renderNode && renderNode->isRenderable()) {
            // compute 3d ordering
            renderNode->computeOrdering();
            if (CC_UNLIKELY(mCaches.drawDeferDisabled)) {
                status = startFrame();
                ReplayStateStruct replayStruct(*this, dirty, replayFlags);
                renderNode->replay(replayStruct, 0);
                return status | replayStruct.mDrawGlStatus;
            }
    
            bool avoidOverdraw = !mCaches.debugOverdraw && !mCountOverdraw; // shh, don't tell devs!
            DeferredDisplayList deferredList(*currentClipRect(), avoidOverdraw);
            DeferStateStruct deferStruct(deferredList, *this, replayFlags);
            renderNode->defer(deferStruct, 0);
    
            flushLayers();
            status = startFrame();
    
            return deferredList.flush(*this, dirty) | status;
        }
    
        // Even if there is no drawing command(Ex: invisible),
        // it still needs startFrame to clear buffer and start tiling.
        return startFrame();
    }

           这个函数定义在文件frameworks/base/libs/hwui/OpenGLRenderer.cpp。

           参数renderNode描述的是应用程序窗口的Root Render Node,如果它的值不等于NULL,并且它是可渲染的,即调用它的成员函数isRenderable的返回值为true,那么接下来就开始渲染的它的Display List。

           在渲染应用程序窗口的Root Render Node之前,OpenGLRenderer类的成员函数drawRenderNode首先调用它的成员函数computeOrdering计算它的Projected Node。这一步与前面LayerRenderer类渲染设置了Layer的Render Node的Display List的过程是一样的,都是为重排那些Projected Node,使得它们的渲染顺序位于要投影到的Render Node的后面。

           OpenGLRenderer类的成员函数drawRenderNode接下来判断当前是否禁止重排应用程序窗口的Root Render Node的Display List的绘制命令,也就是不允许对这些绘制命令进行合并。如果是禁止的话,那么OpenGLRenderer类的成员变量mCaches指向的一个Caches对象的成员变量drawDeferDisabled的值就会等于true。在这种情况下,就会跳过应用程序窗口的Root Render Node的Display List的绘制命令的重排阶段,而直接对它们进行执行。这是通过调用RenderNode类的成员函数replay实现的。

           如果当前不禁止重排应用程序窗口的Root Render Node的Display List的绘制命令,那么OpenGLRenderer类的成员函数drawRenderNode接下来做的事情就是调用前面分析过的RenderNode类的成员函数defer对应用程序窗口的Root Render Node及其子Render Node和Projected Node的的Display List的绘制命令进行合并操作。合并后得到的绘制命令,也就是DrawOp,就以Batch为单位保存在本地变量deferredList描述的一个DeferredDisplayList对象的成员变量mBatches描述的一个Vector中。

           这里有一点需要注意的是,在调用RenderNode类的成员函数defer合并应用程序窗口的Root Render Node的Display List的绘制命令的时候,传递进去的DeferStateStruct结构体封装的Renderer是一个OpenGLRenderer。这意味着如果应用程序窗口的Root Render Node包含了一个设置了Layer的子RenderNode,那么当调用到RenderNode类的成员函数issueOperations递归处理该子RenderNode时候,这个子RenderNode就直接以一个DrawLayerOp进行绘制。这是由于这时候这个子RenderNode的成员变量renderer指向的OpenGLRenderer对象的实际类型是LayerRenderer,而参数renderer指向OpenGLRenderer对象的实际类型就是OpenGLRenderer。这两个OpenGLRenderer对象的不相等,就使得本地变量drawLayer的值等于true,于是该子RenderNode的绘制命令就被封装为一个DrawLayerOp。这样做是合理的,因为这个子RenderNode的Display List的绘制命令之前已经被重排和合并过了。

           重排和合并完成应用程序窗口的Root Render Node及其子Render Node和Projected Node的Display List的绘制命令之后,本来就可以执行它们了。但是在执行它们之前,还有一件事情需要做,就是先执行那些设置了Layer的子Render Node的绘制命令,以便得到一个对应的FBO。这些FBO就代表了那些设置了Layer的子Render Node的UI。这一步是通过调用OpenGLRenderer类的成员函数flush来完成的。

           OpenGLRenderer类的成员函数flush的实现如下所示:

    void OpenGLRenderer::flushLayers() {
        int count = mLayerUpdates.size();
        if (count > 0) {
            ......
    
            // Note: it is very important to update the layers in order
            for (int i = 0; i < count; i++) {
                ......
                Layer* layer = mLayerUpdates.itemAt(i);
                layer->flush();
                ......
            }
    
            ......
    
            mRenderState.bindFramebuffer(getTargetFbo());
            
            ......
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/OpenGLRenderer.cpp。

           从前面的分析可以知道,OpenGLRenderer类的成员变量mLayerUpdates描述的一个Vector里面存放的都是设置了Layer的Render Node关联的Layer,并且这些Render Noder的Display List的绘制命令都是已经经过了重排和合并等操作的。

           对于保存在上述Vector中的每一个Layer,OpenGLRenderer类的成员函数flushLayers都会调用它的成员函数flush,目的就是执行这些Layer关联的Render Node的Display List经过重排和合并后的绘制命令。

           Layer类的成员函数flush的实现如下所示:

    void Layer::flush() {
        // renderer is checked as layer may be destroyed/put in layer cache with flush scheduled
        if (deferredList && renderer) {
            ......
            renderer->prepareDirty(dirtyRect.left, dirtyRect.top, dirtyRect.right, dirtyRect.bottom,
                    !isBlend());
    
            deferredList->flush(*renderer, dirtyRect);
    
            ......
        }
    }
           这个函数定义在文件frameworks/base/libs/hwui/Layer.cpp中。 

           从前面的分析可以知道,这时候正在处理的Layer对象的成员变量renderer和deferredList的值均不等于NULL,它们分别指向了一个LayerRenderer对象和一个DeferredDisplayList对象,因此Layer类的成员函数flush接下来就分别调用了这两个对象的成员函数prepareDirty和flush。

           LayerRenderer类的成员函数prepareDirty的实现如下所示:

    status_t LayerRenderer::prepareDirty(float left, float top, float right, float bottom,
            bool opaque) {
        ......
    
        renderState().bindFramebuffer(mLayer->getFbo());
    
        ......
    
        return OpenGLRenderer::prepareDirty(dirty.left, dirty.top, dirty.right, dirty.bottom, opaque);
    }
           这个函数定义在文件frameworks/base/libs/hwui/LayerRenderer.cpp中。

           LayerRenderer类的成员函数prepareDirty做了一件很重要的事情,就是在从成员变量mLayer指向的一个Layer对象获得一个FBO,并且将该FBO设置当前Open GL环境的渲染对象,这意味着后续的Open GL绘制命令都是将UI渲染在该FBO上。

           LayerRenderer类的成员函数prepareDirty最后还调用了父类OpenGLRenderer的成员函数prepareDirty。前面我们在分析OpenGLRenderer类的成员函数prepareDirty的时候提到,如果当前正在处理的一个LayerRenderer对象,那么它所做的事情是调用OpenGLRenderer类的另外一个成员函数startFrame。OpenGLRenderer类的成员函数startFrame仅仅是负责执行一些诸如清理颜色绘冲区等基本操作。当然,这里清理的是从成员变量mLayer指向的一个Layer对象获得一个FBO的颜色绘冲区。

           这一步执行完成之后,回到Layer类的成员函数flush中,它接下来调用DeferredDisplayList类的成员函数flush,目的是为了将当前正在处理的Layer关联的Render Node的Display List渲染在上述的FBO上。

           DeferredDisplayList类的成员函数flush的实现如下所示:

    status_t DeferredDisplayList::flush(OpenGLRenderer& renderer, Rect& dirty) {
        ......
    
        status |= replayBatchList(mBatches, renderer, dirty);
    
        ......
    
        return status;
    }
           这个函数定义在文件frameworks/base/libs/hwui/DeferredDisplayList.cpp中。

           前面提到,DeferredDisplayList类的成员变量mBatches描述的一个Vector存放的就是一个设置了Layer的Render Node的Display List经过重排和合并后的绘制命令,这些绘制命令通过DeferredDisplayList类的另外一个成员函数replayBatchList执行。

           DeferredDisplayList类的成员函数replayBatchList的实现如下所示:

    static status_t replayBatchList(const Vector<Batch*>& batchList,
            OpenGLRenderer& renderer, Rect& dirty) {
        status_t status = DrawGlInfo::kStatusDone;
    
        for (unsigned int i = 0; i < batchList.size(); i++) {
            if (batchList[i]) {
                status |= batchList[i]->replay(renderer, dirty, i);
            }
        }
        ......
        return status;
    }
           这个函数定义在文件frameworks/base/libs/hwui/DeferredDisplayList.cpp中。

           DeferredDisplayList类的成员函数replayBatchList依次调用参数batchList描述的一个Vector中的每一个Batch对象的成员函数replay。从前面分析的DeferredDisplayList类的成员函数addDrawOp可以知道,参数batchList描述的一个Vector中的每一个Batch对象的实际类型要么是DrawBatch,要么是MergingDrawBatch,因此我们接下来就继续分析DrawBatch类和MergingDrawBatch类的成员函数replay的实现。

           DrawBatch类的成员函数replay的实现如下所示:

    class DrawBatch : public Batch {
    public:
        ......
    
        virtual status_t replay(OpenGLRenderer& renderer, Rect& dirty, int index) {
            ......
    
            status_t status = DrawGlInfo::kStatusDone;
            ......
            for (unsigned int i = 0; i < mOps.size(); i++) {
                DrawOp* op = mOps[i].op;
                ......
    
                status |= op->applyDraw(renderer, dirty);
    
                .....
            }
            return status;
        }
    
        ......
    };
           这个函数定义在文件frameworks/base/libs/hwui/DeferredDisplayList.cpp中。

           DrawBatch类的成员函数replay依次调用存放在成员变量mOps描述的一个Vector中的每一个DrawOp的成员函数applyDraw,以便这些DrawOp可以转化为Open GL绘制命令进行执行。

           以一个具体的DrawRectOp为例,它的成员函数applyDraw的实现如下所示:

    class DrawRectOp : public DrawStrokableOp {
    public:
        ......
    
        virtual status_t applyDraw(OpenGLRenderer& renderer, Rect& dirty) {
            return renderer.drawRect(mLocalBounds.left, mLocalBounds.top,
                    mLocalBounds.right, mLocalBounds.bottom, getPaint(renderer));
        }
    
        ......
    };
           这个函数定义在文件frameworks/base/libs/hwui/DisplayListOp.h中。

           DrawRectOp类的成员函数applyDraw调用了参数renderer描述的一个OpenGLRenderer对象的成员函数drawRect来渲染当前正在处理的一个DrawRectOp。参数renderer描述的一个OpenGLRenderer对象的实际类型为LayerRenderer,不过LayerRenderer类的成员函数drawRect是从父类OpenGLRenderer继承下来的。因此,当前正在处理的一个DrawRectOp最终是通过OpenGLRenderer类的成员函数drawRect转化Open GL绘制命令进行执行的。这一点我们就留给读者自己去分析了。

           还有一种特殊的DrawOp,即DrawRenderNodeOp,当它们的成员函数applyDraw被调用时,它所做的工作实际上递归地将它的子Render Node或者Projected Node的Display List包含的DrawOp转化为Open GL命令来执行,它的实现如下所示:

    class DrawRenderNodeOp : public DrawBoundedOp {
        ......
    
        virtual void replay(ReplayStateStruct& replayStruct, int saveCount, int level,
                bool useQuickReject) {
            if (mRenderNode->isRenderable() && !mSkipInOrderDraw) {
                mRenderNode->replay(replayStruct, level + 1);
            }
        }
    
        ......
    };
           这个函数定义在文件frameworks/base/libs/hwui/DisplayListOp.h中。

           这一点与前面我们分析的DrawRenderNodeOp类的成员函数applyDraw的逻辑是类似的,因此我们就不再详述。

           接下来我们再来看MergingDrawBatch类的成员函数replay的实现,如下所示:

    class MergingDrawBatch : public DrawBatch {
    public:
        ......
    
        virtual status_t replay(OpenGLRenderer& renderer, Rect& dirty, int index) {
            ......
    
            DrawOp* op = mOps[0].op;
            ......
    
            status_t status = op->multiDraw(renderer, dirty, mOps, mBounds);
            ......
            
            return status;
        }
    
        ......
    };
            这个函数定义在文件frameworks/base/libs/hwui/DeferredDisplayList.cpp中。

            MergingDrawBatch类的成员函数replay只调用了保存在成员变量mOps描述的一个Vector中的第一个DrawOp的成员函数multiDraw,但是会将其余的DrawOp作为参数传递给它。
           
           以一个具体的DrawPatchOp为例,它的成员函数multiDraw的实现如下所示:

    class DrawPatchOp : public DrawBoundedOp {  
    public:
        ......  
      
        virtual status_t multiDraw(OpenGLRenderer& renderer, Rect& dirty,  
                const Vector<OpStatePair>& ops, const Rect& bounds) {  
            const DeferredDisplayState& firstState = *(ops[0].state);  
            renderer.restoreDisplayState(firstState, true); // restore all but the clip  
      
            // Batches will usually contain a small number of items so it's  
            // worth performing a first iteration to count the exact number  
            // of vertices we need in the new mesh  
            uint32_t totalVertices = 0;  
            for (unsigned int i = 0; i < ops.size(); i++) {  
                totalVertices += ((DrawPatchOp*) ops[i].op)->getMesh(renderer)->verticesCount;  
            }  
      
            const bool hasLayer = renderer.hasLayer();  
      
            uint32_t indexCount = 0;  
      
            TextureVertex vertices[totalVertices];  
            TextureVertex* vertex = &vertices[0];  
      
            // Create a mesh that contains the transformed vertices for all the  
            // 9-patch objects that are part of the batch. Note that onDefer()  
            // enforces ops drawn by this function to have a pure translate or  
            // identity matrix  
            for (unsigned int i = 0; i < ops.size(); i++) {  
                DrawPatchOp* patchOp = (DrawPatchOp*) ops[i].op;  
                const DeferredDisplayState* state = ops[i].state;  
                const Patch* opMesh = patchOp->getMesh(renderer);  
                uint32_t vertexCount = opMesh->verticesCount;  
                if (vertexCount == 0) continue;  
      
                // We use the bounds to know where to translate our vertices  
                // Using patchOp->state.mBounds wouldn't work because these  
                // bounds are clipped  
                const float tx = (int) floorf(state->mMatrix.getTranslateX() +  
                        patchOp->mLocalBounds.left + 0.5f);  
                const float ty = (int) floorf(state->mMatrix.getTranslateY() +  
                        patchOp->mLocalBounds.top + 0.5f);  
      
                // Copy & transform all the vertices for the current operation  
                TextureVertex* opVertices = opMesh->vertices;  
                for (uint32_t j = 0; j < vertexCount; j++, opVertices++) {  
                    TextureVertex::set(vertex++,  
                            opVertices->x + tx, opVertices->y + ty,  
                            opVertices->u, opVertices->v);  
                }  
      
                // Dirty the current layer if possible. When the 9-patch does not  
                // contain empty quads we can take a shortcut and simply set the  
                // dirty rect to the object's bounds.  
                if (hasLayer) {  
                    if (!opMesh->hasEmptyQuads) {  
                        renderer.dirtyLayer(tx, ty,  
                                tx + patchOp->mLocalBounds.getWidth(),  
                                ty + patchOp->mLocalBounds.getHeight());  
                    } else {  
                        const size_t count = opMesh->quads.size();  
                        for (size_t i = 0; i < count; i++) {  
                            const Rect& quadBounds = opMesh->quads[i];  
                            const float x = tx + quadBounds.left;  
                            const float y = ty + quadBounds.top;  
                            renderer.dirtyLayer(x, y,  
                                    x + quadBounds.getWidth(), y + quadBounds.getHeight());  
                        }  
                    }  
                }  
      
                indexCount += opMesh->indexCount;  
            }  
      
            return renderer.drawPatches(mBitmap, getAtlasEntry(),  
                    &vertices[0], indexCount, getPaint(renderer));  
        }  
      
        ......  
    };  
           这个函数定义在文件frameworks/base/libs/hwui/DisplayListOp.h中。

           在前面Android应用程序UI硬件加速渲染的预加载资源地图集服务(Asset Atlas Service)分析一文中,我们有分析过DrawPatchOp类的成员函数multiDraw的实现,它所做的事情就是首先计算出当前正在处理的DrawPatchOp和参数ops描述的DrawPatchOp的纹理坐标,并且将这些纹理坐标保存一个数组中传递给参数renderer描述的一个OpenGLRenderer对象的成员函数drawPatches,使得后者可以一次性地将N个DrawPatchOp合并在一起转化为Open GL绘制命令执行。这之所以是可行的,是因为这些DrawPatchOp是以纹理方式进行渲染的,它们使用的是同一个纹理。

           这一步执行完成之后,回到OpenGLRenderer类的成员函数flushLayers中,这时候所有设置了Layer的Render Noder及其子Render Node和Projected Node的Display List均已渲染到了自己的FBO之上,接下来就要将这些FBO以及其它没有设置Layer的Render Node的Display List渲染在Frame Buffer上,也就是渲染在从Surface Flinger请求回来的一个图形缓冲区之上。由于前面每调用一个Layer对象的成员函数flush的时候,都会将一个FBO设置为当前的渲染对象,而接下来的渲染对象是Frame Buffer,因此就需要调用成员变量mRenderState描述的一个RenderState对象的成员函数bindFramebuffer将Frame Buffer设置为当前的渲染对象。前面提到,OpenGLRenderer类的成员函数getTargetFbo的返回值等于0,当我们将一个值为0的FBO设置为当前的渲染对象时,起到的效果实际上解除前面设置的值为非0的FBO作为当前的渲染对象,并且将当前的渲染对象还原回Frame Buffer的效果。

           OpenGLRenderer类的成员函数flushLayers执行完成后,回到OpenGLRenderer类的成员函数drawRenderNode中,这时候可以渲染应用程序窗口的Root Render Node的Display List了。在渲染之前,同样是先调用OpenGLRenderer类的成员函数startFrame执行一些诸如清理颜色绘冲区等基本操作。注意,这里清理的是Frame Buffer的颜色绘冲区。这时候应用程序窗口的Root Render Node及其子Render Node和Projected Node的Display List经过重排和合并后的绘制命令就存放在本地变量deferredList描述的一个DeferredDisplayList的成员变量mBatches描述的一个Vector中,因此OpenGLRenderer类的成员函数drawRenderNode就可以调用前面已经分析过的DeferredDisplayList类的成员函数flush来执行它们。这里同样是需要注意,这些绘制命令的执行是作用在Frame Buffer之上的。

           至此,应用程序窗口的Display List的渲染过程就分析完成了。整个过程比较复杂,但是总结来说,核心逻辑就是:

           1. 将Main Thread维护的Display List同步到Render Thread维护的Display List去。这个同步过程由Render Thread执行,但是Main Thread会被阻塞住。

           2. 如果能够完全地将Main Thread维护的Display List同步到Render Thread维护的Display List去,那么Main Thread就会被唤醒,此后Main Thread和Render Thread就互不干扰,各自操作各自内部维护的Display List;否则的话,Main Thread就会继续阻塞,直到Render Thread完成应用程序窗口当前帧的渲染为止。

           3. Render Thread在渲染应用程序窗口的Root Render Node的Display List之前,首先将那些设置了Layer的子Render Node的Display List渲染在各自的一个FBO上,接下来再一起将这些FBO以及那些没有设置Layer的子Render Node的Display List一起渲染在Frame Buffer之上,也就是渲染在从Surface Flinger请求回来的一个图形缓冲区上。这个图形缓冲区最终会被提交给Surface Flinger合并以及显示在屏幕上。

           第2步能够完全将Main Thread维护的Display List同步到Render Thread维护的Display List去很关键,它使得Main Thread和Render Thread可以并行执行,这意味着Render Thread在渲染应用程序窗口当前帧的Display List的同时,Main Thread可以去准备应用程序窗口下一帧的Display List,这样就使得应用程序窗口的UI更流畅。

           Android 5.0引入Render Thread的作用除了可以获得上面描述的效果之外,还可以使得应用程序窗口动画显示更加流畅。在接下来的一篇文章中,我们就继续分析在硬件加速渲染的环境下,应用程序窗口的动画显示框架,敬请关注!更多的信息也可以关注老罗的新浪微博:http://weibo.com/shengyangluo

    展开全文
  • Vulkan【11】渲染过程

    千次阅读 2018-09-07 09:41:59
    创建一个渲染过程 本节的代码是 10-init_render_pass.cpp 渲染过程通过指定在渲染操作期间使用的附件、子过程和依赖项的集合来描述渲染操作的范围。一个渲染过程由至少一个子过程组成。将这些信息与驱动程序...

    创建一个渲染过程

    本节的代码是 10-init_render_pass.cpp

    渲染过程通过指定在渲染操作期间使用的附件、子过程和依赖项的集合来描述渲染操作的范围。一个渲染过程由至少一个子过程组成。将这些信息与驱动程序通信,使驱动程序能够知道在呈现开始时将会发生什么,并为呈现操作设置最优的硬件。

    首先使用vkCreateRenderPass()来定义渲染过程,然后使用vkCmdBeginRenderPass()vkCmdEndRenderPass()来将呈现过程实例插入到命令缓冲区中。

    在本节中,您将只创建并定义渲染过程,而不是在命令缓冲区中使用它。

    在本例的上下文中,渲染过程附件包括颜色附件,颜色附件是交换链里的图像,以及深度/模板附件,它是在之前的样例中分配的深度缓冲。

    图像附件必须准备好,当它们在一个命令缓冲区中执行的渲染过程实例中用作附件时使用。这个准备过程包括将图像布局从最初的未定义状态转换为在渲染过程中使用的最优状态。由于这些布局转换是相当复杂的,您将在这里了解它们,然后继续创建渲染传递。

    图像布局转换

    对备用内存访问模式的需求

    图像的布局是指图像纹理如何从网格坐标表示映射到图像内存中的偏移量。通常情况下,图像数据是以这种方式线性映射的,对于2D图像来说,这可能意味着一排texel存储在相邻的内存中,下一行连续存储在这一行之后,以此类推。

    换句话说:

    offset = rowCoord * pitch + colCoord
    

    pitch是指行的大小。 pitch通常与图像的宽度相同,但是可能包含一些额外的填充字节,以确保图像的每一行从满足GPU的对齐需求的内存地址开始。

    通过改变colCoord,线性布局对于连续的texel读或写在一行中是可以的。但是大多数图形操作都涉及到通过改变rowCoord来访问多个相邻行的texel。如果图像宽度相当宽,那么这些相邻的行就会在线性内存地址空间中引入相当大的跳跃。这可能会导致性能问题,比如由于TLB遗漏和多层缓存内存系统中的缓存遗漏而导致的内存地址转换较慢。

    为了解决这些低效率问题,许多GPU硬件实现支持“最佳”或平铺内存访问方案。在一个最优的布局中,出现在图像中间的一个矩形的纹理被存储在内存中,这样所有的texel都处于一个连续的内存段中。例如,构成一个矩形的texel,在16,32和右下角的31,47,可能会看到这个16 x 16块的texel,连续地从一个地址开始存储。行之间没有长间隙。

    如果GPU想要填充这个块,例如,用一个纯色的颜色,它就可以用少量的内存系统开销来写这个256个texel block。

    这里有一个简单的2x2网格方案的例子。注意,在线性方案中,蓝色的texel可以彼此相隔很远,而它们在平铺的模式中是相邻的。

    这里写图片描述

    大多数实现使用更复杂的平铺模式和大于2x2的网格大小。

    Vulkan对布局的控制

    正如上面所解释的那样,GPU硬件通常倾向于优化布局,以实现更高效的渲染。最优布局通常是“不透明的”,这意味着优化布局格式的细节不会被发布,也不会让其他需要读取或写入图像数据的组件知道。

    例如,您可能希望GPU使用最优布局呈现给图像。但是,如果您希望将生成的图像复制到一个您可以使用CPU读取和理解的缓冲区中,那么在尝试读取之前,您可以将布局从最优变为一般。

    从一个布局到另一个布局的转换称为Vulkan中的布局转换。您可以控制这些转换,并且可以通过以下三种方式调用它们:

    1. 内存屏障指令 (通过vkCmdPipelineBarrier)
    2. 渲染最终布局规范
    3. 渲染过程子过程规范

    内存屏障命令是一个显式的布局转换命令,您可以在命令缓冲区中设置。例如,您将使用这个命令在更复杂的情况下同步内存访问。由于您将使用另外两种方法来执行布局转换,所以您不会在本教程中使用这个barrier命令。

    更常见的情况是,在渲染开始之前和渲染完成后,需要对渲染的图像进行布局转换。第一个转换为GPU的渲染准备了图像,最后一个转换为显示图像到显示器做准备。在这些情况下,您指定布局转换作为渲染过程定义的一部分。稍后您将在本节中看到如何做到这一点。

    布局转换可能会,也可能不会触发实际的GPU布局转换操作。例如,如果旧的布局没有定义,而新的布局是最优的,那么GPU将不得不做其他的工作,而不是通过编程GPU硬件来访问最优模式的内存。这是因为图像的内容没有定义,不需要通过转换来保存。另一方面,如果旧的布局是通用的(非最优的)并且有迹象表明图像中的数据需要被保留,那么向优化布局的转换可能涉及到GPU对图像的一些工作。

    即使您知道或认为布局转换实际上不会做任何工作,但最好还是去做一下,因为它给了驱动程序更多的信息,并帮助确保您的应用程序在更多的设备上运行。

    例子中的图像布局转换

    样例代码使用子过程定义和渲染过程定义来指定所需的图像布局转换,而不是使用内存屏障命令。

    Render Pass Layout

    初始的渲染过程的布局是没有定义的,意思是“不关心”,因为当渲染过程开始时,你不会关心图像中已经存在的内容,因为无论如何你都要把它画出来。在这里,您只是告诉驱动程序在渲染过程开始时对图像的布局是什么。驱动程序在子过程或直到渲染结束时才会进行转换。

    子过程布局被设置为颜色缓冲区的最优选择,这表明在子过程的渲染操作期间驱动程序应该将布局转换为最优。样例代码为深度缓冲设置了类似的设置。

    最后的渲染过程布局告诉驱动将布局转换为适合显示器显示的布局。

    创建渲染过程

    现在您已经知道了如何将图像布局转换为正确的状态,您可以继续定义剩余的渲染过程。

    附件(Attachments)

    有两个附件,一个用于颜色,一个用于深度:

    VkAttachmentDescription attachments[2];
    attachments[0].format = info.format;
    attachments[0].samples = NUM_SAMPLES;
    attachments[0].loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
    attachments[0].storeOp = VK_ATTACHMENT_STORE_OP_STORE;
    attachments[0].stencilLoadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
    attachments[0].stencilStoreOp = VK_ATTACHMENT_STORE_OP_DONT_CARE;
    attachments[0].initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
    attachments[0].finalLayout = VK_IMAGE_LAYOUT_PRESENT_SRC_KHR;
    attachments[0].flags = 0;
    
    attachments[1].format = info.depth.format;
    attachments[1].samples = NUM_SAMPLES;
    attachments[1].loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR
    attachments[1].storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE;
    attachments[1].stencilLoadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
    attachments[1].stencilStoreOp = VK_ATTACHMENT_STORE_OP_DONT_CARE;
    attachments[1].initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
    attachments[1].finalLayout = VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL;
    attachments[1].flags = 0;
    

    在两个附件中设置loadOp成员为CLEAR,表明您希望缓冲区在渲染过程实例的开始处被清空。

    为颜色附件设置storeOp成员为STORE意味着您想要将渲染结果留在这个缓冲区中,这样它就可以显示给显示器了。

    storeOp成员设置为 DONT_CARE的深度附件意味着当渲染过程实例完成时,您不需要缓冲区的内容。告诉驱动程序,在使用缓冲区后,您不关心缓冲区的内容,这是很有用的,因为它允许驱动程序在不保存内容的情况下丢弃或删除该内存。

    对于图像布局,您可以指定颜色和深度缓冲,以开始未定义的布局,如前所述。

    子过程发生在初始布局和最终布局之间,将颜色附件设置为VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL,深度附件设置为VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL

    对于颜色附件,您可以指定最终的布局为VK_IMAGE_LAYOUT_PRESENT_SRC_KHR布局,这是最适合显示操作的,该操作是在渲染过程完成之后发生的。您可以将深度布局与子过程设置的布局相同,因为深度缓冲不作为显示操作的一部分使用。

    子过程

    子过程的定义很简单,如果你在做多个子过程,会更有趣。如果你正在对你的图形数据进行预处理或后期处理,可能会对环境光遮蔽或其他一些效果进行处理,你可能会对多次子过程感兴趣。但是在这里,子过程定义对于在子过程表示哪些附件是活动的,以及在子过程中渲染时使用的布局是很有用的。

    VkAttachmentReference color_reference = {};
    color_reference.attachment = 0;
    color_reference.layout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
    
    VkAttachmentReference depth_reference = {};
    depth_reference.attachment = 1;
    depth_reference.layout = VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL;
    

    attachment成员是您刚才为渲染过程所定义的附件数组中的附件的索引。

    VkSubpassDescription subpass = {};
    subpass.pipelineBindPoint = VK_PIPELINE_BIND_POINT_GRAPHICS;
    subpass.flags = 0;
    subpass.inputAttachmentCount = 0;
    subpass.pInputAttachments = NULL;
    subpass.colorAttachmentCount = 1;
    subpass.pColorAttachments = &color_reference;
    subpass.pResolveAttachments = NULL;
    subpass.pDepthStencilAttachment = &depth_reference;
    subpass.preserveAttachmentCount = 0;
    subpass.pPreserveAttachments = NULL;
    

    pipelineBindPoint成员的意思是表示这是一个图形还是一个计算子过程。目前,只有图形子过程是有效的。

    渲染过程

    现在你已经拥有所有用来定义渲染过程的东西了:

    VkRenderPassCreateInfo rp_info = {};
    rp_info.sType = VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO;
    rp_info.pNext = NULL;
    rp_info.attachmentCount = 2;
    rp_info.pAttachments = attachments;
    rp_info.subpassCount = 1;
    rp_info.pSubpasses = &subpass;
    rp_info.dependencyCount = 0;
    rp_info.pDependencies = NULL;
    res = vkCreateRenderPass(info.device, &rp_info, NULL, &info.render_pass);
    

    您将在几个即将到来的示例中使用渲染过程。

    © Copyright 2016 LunarG, Inc

    展开全文
  • 三维渲染过程

    千次阅读 2017-03-28 16:23:37
    三维渲染过程 三维成像过程   三维成像的过程,相对二维来说比较复杂,但是也并不是很难理解。   由于显示屏是二维的,所以二维成像很简单,只需要把图像逐个像素设置正确,直接显示到屏幕...
  • 读写style对渲染过程的影响一直都说操作DOM性能很差,那么为什么差呢?读写style会给性能造成什么影响?本文作为渲染性能的第一篇(从发布时间来看)其实不太合适,第一篇应该先和大家简单介绍浏览器对于页面的渲染...
  • JavaScript异步加载和网页渲染过程

    千次阅读 2020-03-11 22:50:15
    页面的渲染过程:DOMTree + CSSTree = renderTree 构建文档对象模型(DOM) 构建CSS对象模型(CSSOM) 构建渲染树(Render Tree) 布局(Layout) 绘制(Painting) 什么是同步(Synchronous)加载? 我们平...
  • 3D max 的一个大堂的渲染过程一个大堂的渲染过程一个大堂的渲染过程
  • 浏览器的渲染过程: 解析 HTML 构建 DOM(DOM 树),并行请求 css/image/js CSS 文件下载完成,开始构建 CSSOM(CSS 树) CSSOM 构建结束后,和 DOM 一起生成 Render Tree(渲染树) 布局(Layout):计算出每个节点在...
  • CSS经过解析生成 Style Rules。 二者一结合生成了Render Tree。...浏览器的渲染过程: 解析 HTML 构建 DOM(DOM 树),并行请求 css/image/js CSS 文件下载完成,开始构建 CSSOM(CSS 树) CSSOM ...
  • Unity3D - Shader - 渲染过程

    千次阅读 2017-12-05 21:02:48
    渲染过程渲染过程 - 通常从是三维场景出发、生成一张二维图像,由CPU和GPU共同合作完成。
  • Vue是如何渲染页面的,渲染过程以及原理代码:https://www.cnblogs.com/ypinchina/p/7238402.html 转载于:https://www.cnblogs.com/bydzhangxiaowei/p/9080336.html
  • 摸鱼前端的自检(一)浏览器渲染过程剖析

    千次阅读 多人点赞 2019-10-31 15:43:22
    浏览器渲染过程剖析 作为一个前端,不了解浏览器在干什么,不是个合格的前端哦~ 有兴趣的同学可以去我的github,里面有我的分享的学习过程和blog. github.com/193Eric 首先先贴一张图,网上找的~ 我们可以看到,...
  • 文章目录前言浏览器渲染过程浏览器渲染步骤重排重绘解析实例演示只修改背景色只修改宽度总结 前言 前端人员可能不太了解浏览器渲染Html的过程,或者了解相关知识,但是不能通过具体的方式来更深入认识。 本文通过...
  • 浏览器渲染过程

    千次阅读 2016-10-08 11:01:52
    为什么要了解浏览器加载、解析、渲染这个过程? 了解浏览器如何进行加载,我们可以在引用外部样式文件,外部js时,将他们放到合适的位置,使浏览器以最快的速度将文件加载完毕。 了解浏览器如何进行解析,我们可以...
  • GLSurfaceView渲染过程详解

    万次阅读 2016-08-24 18:56:14
    GLSurfaceView提供了下列特性...2> 管理一个EGL display,它能让opengl把内容渲染到上述的surface上。 3> 用户自定义渲染器(render)。 4> 让渲染器在独立的线程里运作,和UI线程分离。 5> 支持按需渲染(on-demand)和连
  • 看过http://www.cnblogs.com/liangliangh/p/4116164.html这篇关于固定管线的渲染过程, 但是还是有一些细节不太了解。 管线的一系列流程(着色器什么的)是发生在gpu还是cpu 中的,cs模型中 c给s输入是vertex和...
  • Vuejs基本知识(四)【页面渲染过程

    千次阅读 2018-12-20 10:09:47
    Vuejs 渲染页面的过程和...渲染过程1. js入口文件 最初的最初,我们要知道 ./build/webpack.base.conf.js 这个文件,是webpack打包的主要配置文件. 一个典型的代码如下: var path = require('path') var utils ...
  • 这一篇主要讲述了GPU的渲染过程,这一篇可谓最为基础的重点,所以我们必须将其牢记于心。 图形绘制管线分为三个阶段: **应用程序阶段、几何阶段、光栅阶段**
  • android4.0.1 webkit 硬件渲染过程分析

    千次阅读 2013-02-12 16:02:46
    硬件渲染也可以分为三个部分,其中前两个部分与软件渲染相同。...下面的图是webkit 硬件渲染过程涉及的主要类的类图。 类图下载地址 下图是硬件渲染过程中paint的详细顺序图。 顺序图下载地址 也是从w
  • 浏览器页面渲染过程

    千次阅读 2018-08-16 16:51:30
    浏览器渲染页面的一般过程:1.浏览器解析html源码,然后创建一个 DOM树。 在DOM树中,每一个HTML标签都有一个对应的节点,并且每一个文本也都会有一个对应的文本节点。DOM树的根节点就是 documentElement,对应的是...
  • MyGui笔记(4)渲染过程

    千次阅读 2013-10-18 00:30:56
     MyGui的渲染过程比较复杂,这里仅记录一下一些要点,如有错误的地方,还请指出。在第一篇有提到在BaseManager::run函数里面进行每一帧的绘制,调用的是drawOneFrame()方法,这个方法代码如下:  1 2
  • OpenGL的图形渲染过程

    千次阅读 2019-06-03 08:31:09
    管线这个术语描述了opengl渲染的整个过程。openGL采用cs模型:c是cpu,s是GPU,c给s的输入是vertex信息和Texture信息,s的输出是显示器上显示的图像。下面这2个图比较清楚的讲解了opengl的渲染管线。 ...
  • iOS 事件处理机制与图像渲染过程·iOS RunLoop都干了什么·iOS 为什么必须在主线程中操作UI·事件响应·CALayer·CADisplayLink 和 NSTimer·iOS 渲染过程·渲染时机·CPU 和 GPU渲染·Core Animation·Facebook Pop...
  • 最近一直想看看浏览器渲染以及前端性能优化的内容,可是在网上找到的都是文字描述,所以想通过网上的知识去对应到chrome performance看到的过程。 先看一个非常简单的页面代码: Test dom load.
  • html 渲染过程详解

    千次阅读 2018-08-22 15:01:47
    https://www.cnblogs.com/dojo-lzz/p/3983335.html
  • html页面的渲染过程

    千次阅读 2017-11-18 20:15:29
    最近在学习前端的性能优化,有必要了解一下页面的渲染流程,以便对症下药,找出性能的瓶颈所在。以下是我看到的一些东西,分享给大家。 参考:Understanding the renderer 页面的渲染有以下特点: 单线程...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 282,260
精华内容 112,904
关键字:

渲染过程