I've implemented this on the tiling branch: http://hg.mozilla.org/users/bschouten_mozilla.com/tiling
Initial results are not good - our current Gralloc TextureSource has a very expensive BindTexture implementation (most of the time on a profile is spent in EGLImageTargetTexture2D). This may or may not be helped by state tracking, but it may just be an attribute of gralloc that is has an expensive bind. This would make it a bad choice for using with tiles, in this way at least.
We're experimenting and trying to think of alternatives. Here's a few:
- Don't use Gralloc for tiles and just use the shmem path (that works quite well and seems to perform adequately for our use-case)
- Don't use Gralloc, but use EGLImage to move the texture upload into either another thread, or onto the content process
- Copy from the gralloc texture to another texture (and hopefully this is faster than uploading from shmem, or it'd be pointless)
- Find out why using Gralloc in this way is slow and see if there's anything that can be done, at either application or driver level (we have this kind of relationship, right?)

(In reply to Chris Lord [:cwiiis] from comment #1)
> - Don't use Gralloc, but use EGLImage to move the texture upload into either
> another thread, or onto the content process
We were thinking about this way back when the Fennec native rewrite was going on, and I still think it could be a solid idea.