More looking into the current state of how browsers do rendering has led me to skia:
http://www.chromium.org/developers/design-documents/graphics-and-skiaThat document states "Chrome uses Skia for nearly all graphics operations" ... "There was already a high-quality Webkit/Canvas port to Skia.".
Firefox also contains what looks like a complete skia backend for both azure and their older 2D API (it is used for all drawing on Android).
I haven't looked into how portable it is, but it seems to just treat a block of memory as a bitmap and draw into there. In chrome on windows they even share the same memory with GDI, as that is used for ClearType text rendering. Skia has a few platform text backends by the look of it- freetype, OSX, and GDI.
How is our current WebKit gfx backend coded? I assume it's a custom BeAPI wrapper for all drawing functions. In practice that currently means all drawing commands get sent to the app server, where AGG rasterizes them onto a bitmap. I suspect having skia render directly client-side into shared memory would be significantly faster. There are potentially two big wins:
- The big G use skia for all their rendering -> this makes them care greatly about performance, and ensure all drawing functionality required by web standards is supported; Affine transformations, etc.
- WebKit has a very actively maintained skia backend - It appears firefox can use skia for rendering tooOne annoyance - skia seems to assume BGRA byte order on little-endian machines. Is there app-server support for that?
Simon
