History

In the past GrTextures maintained two sizes: allocated and content. The GrGpu class would tweak the texture matrix so that the standard unit tex coord square would map to the content region. We did this for three reasons:

1) GLs without NPOT texture support. The need for this is gone now that we no longer support ES1. (We now require GL 2.0 or GL_ARB_texture_non_power_of_two.)

2) Some SGX gpu/drivers don't seem to support FBOs where width/height is smaller than some small number (e.g. 16) so we rounded up to this min size.

3) One gpu/driver combo did not allow NPOT textures to be bound to FBOs. It was an old Intel GMA gpu and driver.

This caused the code to be harder to maintain and presented complications to recycling textures from the cache with content dimensions that didn't match their allocated dimensions. Because we sometimes buffer rendering with references to GrTexture objects we couldn't just change the content size to match a cache request as it might affect queued draws.

We've decided that for the time being we are no longer working around driver issues 2) and 3).

Proposal

Going forward we'd add a lightweight abstraction above GrTexture called GrTextureView. It would have a rectangle. a pixel config, and ptr to a GrTexture. The subrect defines a domain in the texture. Texture coordinates are scaled to this domain automatically by modifying the texture matrix sent to GL. This would also tie into the current texture-domain code that limits coords to rectangle. The config would allow the same scratch texture to be recycled both for requests that specify RGBA_premul and RGBA_unpremul (since under the hood they use the same GL format). This scheme would be useful for texture atlasing and simplify some of the code that computes textures coords/mats for scratch textures that may not match the requested width / height.

If we had to reinstate workarounds for the driver issues in 2) or 3) they'd use this framework rather than have each texture maintain two widths/heights.

On some GPUs NPOT textures are supported but are less performant. We don't do anything about this today. If we were to start rounding up textures on these platforms to POT we'd use this GrTextureView scheme.