Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU

We are proud to announce the TyGL port (link: on the top of EFL-WebKit. TyGL (pronounced as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on embedded systems. The engine is purely GPU based. It has been developed on and tested against ARM-Mali GPU, but it is designed to work on any GPU conforming to OpenGL ES 2.0 or higher.

The GPU involvement on future graphics is inevitable considering the pixel growth rate of displays, but harnessing the GPU power requires a different approach than CPU-based optimizations. 2D graphics is traditionally software-based however, and 2D APIs are interfaces to these CPU-based algorithms. WebKit GraphicsContext API is no different, so the key challenge of our project was and is producing the expected output in a GPU friendly way.

Key features:

  • Batching pipeline

GPU provides the highest performance when a large number of triangles are drawn with a single draw command without any OpenGL state changes. The GraphicsContext API in WebKit provides draw operations for single shapes however, which can result frequent state changes if implemented naively. TyGL was designed to group these commands to reduce the number of draw calls.

  • Automatic shader generator

TyGL can generate complex shaders from multiple shader fragments, which allows efficient batching but it also takes care to make them fit into the shader cache of the GPU.

  • Trapezoid based path rendering

TyGL uses trapezoid-based tesselation of shapes and the GPU renders them with high anti-aliasing quality. We are continuously improving this part of the engine and look forward to make use of new GPU capabilities (like Pixel Local Storage) to squeeze out more performance out of it.

  • No software fallback

The whole engine is optimized for GPU without legacy software fallback. Hence we don't need to sacrifice optimizations for compatibility. There are enough software based 2D libraries which can be used when GPU is not available.

TyGL is already capable of rendering many web-sites correctly, but some features have not been implemented yet. We continue this work and we are open to contributions from the community. Contact to us if you want more information about the project.

U-Szeged's web browser team.

Yushuang (not verified) - 11/17/2014 - 03:02

Great works!

I am a engineer come from AllwinnerTech, which is a IC design company located in China,Zhuhai.

I heard about this great project from our ARM partners in this year,June, and looking forward to your publish from that moment on.

We are very curious about the performance/power consumption of the TyGL compared to original port, and would likely to do some estimation works in our platforms. So, if you feel convenient, could you give us some guide/advice to help us more efficient to understand this great works ?
Appreciate your any reply.

Best Regards,

Jin Yang (not verified) - 11/19/2014 - 14:21

What's the advantage comparing with Skia GPU backend? Skia GPU backend has already done many optimization on the GPU 2D rendering.

zoltan.herczeg - 11/19/2014 - 14:51

I have limited knowledge about SKIA GPU backend. If you could provide a documentation about its internal design, I could compare it to our solution. In general I suspect they try to accelerate the software code path, while we don't have to worry about compatility. This is likely where we have advantage compared to other engines. Our whole engine is focused around "how to give a lot of work to GPU" because GPU is very inefficient when it needs to do a little work. Especially tile based embedded GPUs. They are optimized for full screen rendering, not changing a few pixels.

zoltan.herczeg - 11/19/2014 - 14:53

We are currently preparing followup blog posts about performance and other designs.

Konsta Karsisto (not verified) - 11/20/2014 - 10:37

I have the impression that the Skia GPU backend does not really optimize (batching, etc.) rendering operations for GPU, it just renders using GPU... haven't checked the current situation, though.

On a related note, the Android UI framework HW acceleration does not utilize the Skia GPU back end. Instead, it stores rendering operations into its own display lists, and implements some optimizations...

Balazs Kelemen (not verified) - 11/26/2014 - 00:56

You guys rock! Big thanks for opening this incredible work.

Looking forward for follow-up under the hood posts.

Jasbir (not verified) - 12/23/2014 - 11:41

Does this only work against a X11 backend with EGL/GLES? I don't think Webkit supports a linux framebuffer with EGL/GLES.

zoltan.herczeg - 01/05/2015 - 06:34

Yes, it is currently only X11 with EGL/GLES. We need inter-process texture sharing, and there is no platform independnet solution for that at the moment.

If you are interested in the technical details, there was a presentation about the engine in WebEngines Hackfest 2014. The slides can be downloaded from here:

Mikko Mononen (not verified) - 02/19/2015 - 09:26

Hi, what do you use for anti-aliasing? I'd guess MSAA from a quick glance at the code, but not sure.

zoltan.herczeg - 02/19/2015 - 09:49

We use shader based anti aliasing, because MSAA only allowed for fbo(0) on most embedded GPUs (and usually only 4x, while we need 256x to match cairo). We need to render textures directly.

Mikko Mononen (not verified) - 02/19/2015 - 12:20

Thanks! I think I found the relevant code. Is it based on some algorithm I could look up to learn more about it? Any edges cases where it does not work as well as you hoped?

I've written a OpenGL vector drawing lib called NanoVG, and I expand the geometry to draw the AA fringes. It has problems on thin geometry, and I would l like to find and alternative at some point.

zoltan.herczeg - 02/19/2015 - 15:38

Our path rendering is based on trapezoid partitioning. The idea is very old (originates from the 80's), but it hasn't been popular since scanlining is much better choice on CPUs.

Trapezoid partitioning is kind of an "extension" of scanlining where the scanline height is arbitrary and the edges are not necessary vertical. All shapes are partitioned into a list of non-intersecting trapezoids, and we use a shader to compute coverage data (how much of a pixel is covered by the currently processed trapezoid). In GLES2 we need to draw each trapezoid as two triangles, but in GLES3 we could use quads instead.

Mikko Mononen (not verified) - 02/19/2015 - 16:03

Thanks! One more question about the AA.
Say, you have a diamond shape: (3.5, 0), (7,4.5), (3.5, 9), (0,4.5). That would consist of two trapezoids on top of each other, the trapezoids would share an edge at y=4.5. Is the vertical AA accumulation along that seam handled using frame buffer?

zoltan.herczeg - 07/13/2015 - 07:41

We use a local texture for that. But we also experimenting using pixel local storage.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • No HTML tags allowed
  • Lines and paragraphs break automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Fill in the blank