If we need to remake the glyph atlas texture but the size is the same, then reuse the old texture.

For more context, see flutter/flutter#138798 which is much slower in Impeller. This change does not fix the problem by itself.

…52563)

Work towards flutter/flutter#138798

Allow cloning a rectangle packer with all existing skylines preserved, but the size increased. This will allow us to preserve the positioning and state of all glyphs when the atlas size is increased, which is necessary for the "blit contents to top right of new texture" approach for improving append performance.
EDIT: I mean top left!

… blit pass to set contents in glyph atlas. (#52510)

part of flutter/flutter#138798

Works around flutter/flutter#144498 for the glyph atlas.

Adds BlitPass::AddCopy implementation for GLES, which is mostly a copy of Texture::SetContents. Updates the glyph atlas to use a blit pass and device private textures instead of set contents (which is unsafely on Metal).

This also removes DeviceBuffer::AsTexture, which isn't actually used anywhere - and creates a linear texture on iOS (and fails with an unsupported API on simulators).

Note that in general, we don't actually have support for hostVisible textures on GLES _or_ Vulkan. Instead, VMA is falling back to device private textures. We may want to, separately, remove the concept of host visible from textures - and similarly remove the concept of transient from buffers.

… of origin for buffer to texture copies. (#52555)

Based on #52510

Work towards flutter/flutter#138798

Change IPoint destination_origin to IRect destination_region, which allows us to specify an area smaller than the entire texture to replace. This will eventually allow us to only upload individual glyphs. This fixes the cubemap issue I previously hit: each face needs to track initialization separately.

…of SkBitmap. (#52567)

Work towards part of flutter/flutter#138798

Allow updating single glyphs in the glyph atlas, without replacing the entire bitmap. Required to efficiently append/update to large atlases.

Fixes flutter/flutter#148251

Work towards flutter/flutter#138798

The rectangle packer was only filling up the top and right edge of each rectangle, making the atlas super inefficient.

…t black. (#52791)

Alternative to #52746

Work towards flutter/flutter#138798

If possible, use a render pass to clear texture to transparent black. The goal is to reduce the CPU cost for larger atlases.

Now that we no longer have a full CPU copy of the glyph atlas, it should be cheaper to make a larger initial atlas to reduce churn from resizing seen in applications like flutter/flutter#138798

Requires #52746

…ull. (#52849)

Fixes flutter/flutter#138798

As far as I can tell, this gets us about as good as Skia, modulo the actual cost of rasterizing one of these glyphs is much more expensive for us.

The basic strategy is:

1. If the existing atlas texture has room (defined by the rect packer addRect call succeeding) append as many glyphs as we can to the old texture.
2. Check if there were any remaining glyphs. If not return.
3. Otherwise, double the size of the texture and create a new rect packer that represents only the increased area. So for example if you doubled a 100x100 texture to 100x200, then you'd create another 100x100 rect packer, assuming the old one is full.
4. Grow this size until all remaining glyphs fit. Store the new rect packer and the "height adjustment", which basically tells you where along the y-axis the rect packer offset starts.
5. Allocate this new texture, clear it, and then blit the contents of the old texture into the top left corner. Append all additional glyphs. The allows us to recycle all previously rendered glyphs and keep them in the texture, reducing the amount of software rasterization per frame.
6. Note; if the max atlas size would be exceeded, throw it away and start again.