Enable Accelerated Compositing on the WebKit Android NDK port && Texture Mapper

liumf2005

于 2014-05-07 13:55:13 发布

阅读量685

点赞数

分类专栏： webkit

webkit 专栏收录该内容

132 篇文章 0 订阅

订阅专栏

http://www.dorothybrowser.com/enable-accelerated-compositing-on-the-webkit-android-ndk-port/

Enable Accelerated Compositing on the WebKit Android NDK port

July 7, 2011 By dorothy With no comments yet Tagged with: accelerated, android, compositing, texture,WebKit

As the previous articles said, our team ported the latest WebKit engine to the Android platform from scratch, and we named it WebKit Android NDK port. The project was to develop a web engine that conforms with WAC 2.0 based on the latest WebKit code, supports JS remote debugging and SVG, and enables various GPU accelerations on the Android platform. In this article I will tell you how we enabled the Accelerated Compositing on the port. I will also compare its rendering performance with the original Android port’s.

What is the Accelerated Compositing?

Web pages are composed of many layers to represent their contents, and browsers render each and every layer to the window on every repaint, iteratively. This means that the browser has to render all the layers of a page even if only a single layer has been changed.

We wanted to reduce unnecessary work with the Accelerated Compositing. The main idea was not to repaint the unchanged layer, but to render each layer to a prepared canvas, so that if a layer is changed, the browser repaints only the changed layer and composes it with the other pre-rendered layers. I recommend you read the Chromium blog article[1] for the more details.

What is the Texture Mapper?

As of porting it, there were several ports which implemented the Accelerated Compositing including Chromium, Mac and Qt. Our choice was the Texture Mapper, which was originally written by Qt. We chose it because first, it had the most simple structure and a clearly separated porting layer, so it was relatively easy to port it without structural changes. Second, Texture Mapper implementation was the only that directly uses OpenGL APIs, and does not depend on other graphics backend such as CoreGraphics. This was important for us because we didn’t want port huge graphics backend for this relatively tiny work. For the details of the Texture Mapper, read this Qt blog[2].

So what did we do?

We had to do three simple things to enable Texture Mapper-based Accelerated Compositing.

we replaced the imagebuffer backend of the BitmapTexture with our own backend. BitmapTexture is an abstraction layer of OpenGL texture which is implemented using QImage and QPainter. We replaced it with SkBitmap and SkCanvas, because Android NDK port already uses Skia as its graphics backend.
we ported the OpenGL based code to OpenGL-ES based one because the Android platform only provided OpenGL-ES.
we implemented the TextureMapperLayerClient on the API layer. We had to implement few callback functions exposed to the API layer of Texture Mapper. These are mostly for synchronizing and drawing the composited layers which are the output of the Accelerated Compositing.

That’s all. Although we had to patch some bugs while we ported the Texture Mapper, it works perfectly with minimum effort. I believe the Texture Mapper is the easiest way to enable Accelerated Compositing on any port. Thanks to Qt guys!

How much does the Accelerated Compositing boost up?

You can see how the Accelerated Compositing boosts up the speed of HTML5 animations and transitions on the next video. This video compares the repainting speed of the default Android browser and the Android NDK port. The left side browser of the video is an Android default browser slightly modified to show its FPS for the comparison. Look at the FPSs on the top of both browsers!

As you can see, the Android NDK port shows up to 3 times higher FPS than the default browser in the test pages with heavy html5 animations. It is even up to 10 times faster in the last test.