render issue on very high atlas pressure

[jerch]

See #4480 (comment).

[jerch]

Thats what happens with the texual easing example, after the texture atlas did a 4 * 1024px page merge (see the log output at the right side, which tracks the number of atlas pages and the page sizes of the merge events):

While the first page merges from 512 --> 1024 work now, the first attempt of a 1024 --> 2048 merge scrambles output.

Edit: Seems only to happen in webgl, in canvas renderer the 1024 --> 2048 transition works.

[jerch]

Repro'ed the webgl issue with this helper script:

const TEXT = '!"#$%&\'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~';

async function stress() {
  for (let fr = 0; fr < 256; fr += 2) {
    for (let fg = 0; fg < 256; fg += 2) {
      for (let fb = 0; fb < 256; fb += 2) {
        console.log('\x1b[H\x1b[2J\x1b[mThis should be readable with white FG color.');
        console.log(`r: ${fr} g:${fg} b:${fb}`);
        console.log(`\x1b[38;2;${fr};${fg};${fb}m${TEXT}`);
        await new Promise(r => setTimeout(r, 20));
      }
    }
  }
}

stress();

The canvas renderer does not suffer the same, but errors out much later with:

Seems the atlas page merge tries to do a [4096, 4096, 4096, 4096] --> 8192 page transition, but fails on that. Whats really weird - a few lines above in the log there are those [512] and [512, 512] entries, with only one resp. 2 pages to merge, which def. wont work in a quadmerge. (The log entries are from console.log(mergingPages.map(p => p.canvas.width)); as first line in TextureAtlas._mergePages).

Idk yet what this error is about, seems the texture atlas is really broken at that stage. A quick fix could just clear the whole atlas at a certain threshold, before it runs into the corrupted state.

[jerch]

@Tyriar I think there is a bug somewhere in the quadmerge logic. While the early merged pages form a nice tree with good fill percentage, the late quadmerges are pretty empty:

• early pages:
  
• late pages:
  

[Tyriar]

I think there's an issue open for this, just haven't got around to it as the chance it happens in practice is very low

[Tyriar]

This was the issue I was thinking of #4351, guess we can track them separately

[jerch]

Oh well #4351 looks like it might be the same as behind the webgl behavior for 1024 --> 2048 above. So yeah these are prolly 2 different issues still.