[webkit-dev] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU

[Zoltan Herczeg]

Hi,

> What makes the 2D drawing code WebKit-specific? Is it possible to package
> up the rendering code into a self-contained standalone library?

It is possible to make it a standalone library in the future. But we are
working on WebKit, we want to accelerate WebKit graphics, and WebKit has a
nice low-level infrastructure we don't want to duplicate. At least for
now.

> Regarding text, do you have a strategy for instancing geometry or using a
> glyph atlas? Did you implement the Loop Blinn path algorithm?

For fonts, we use glyph atlas at the moment. We don't use Loop-Blinn,
since it has some issues with self-intersecting paths. Instead we use fast
trapezoid partitioning. To achieve high anti-aliasing quality, we need to
draw the path onto an internal texture first, which is slow because of
texture fbo binding. However, if multiple paths are drawn (which is a
frequent case), we draw multiple paths onto a single texture, so no fbo
rebinding is needed. We hope Pixel Local Storage extension will eliminate
the need of temporary images at all. It provides the freedom we need for a
2D engine allowing since all temporary data can be kept on GPU.

> Did you experiment with attempting to re-order independent drawing
> commands to achieve high GPU occupancy?

We know overdraw is costly, and we want to use opacity information to
reorder / drop unnecessary draws in the future. But this wasn't the
biggest issue we had so far. My personal experience is that GPUs are very
fast, after the "fbo rebinding cost" is paid. I did not see much
difference of drawing a hundred or a thousand triangles (at least not a
linear increment), except if the shader is very costly. Copy data between
CPU and GPU is also very costly (and glReadPixels runtime is not
predictable), so it is very important to keep data on textures. For
example, we use inter-process texture sharing to transmit Cooridnated
Graphics updates between the UI and Web process.

> Are you measuring power use in addition to time-based performance?

Not yet.

> It sounds like OpenGL is doing the drawing itself; I would imagine there
> are many many draw calls per webpage. Does the OpenGL driver introduce
> significant overhead?

Yes, that is why we use batching. And we still want to improve that, since
we see significant improvement with clever batching.

> Are you thinking of publishing your findings? I would be very interested
> to read about design decisions you encountered along the way.

Well, it is true we found many surprising issues and had to redesign core
algorithms several times. Tile based embedded GPUs has unique strengths
and weaknesses.

Regards,
Zoltan