Extended support for mipmaps level settings for compressed textures

[krapnikkk]

• Extended support for mipmaps level settings for compressed textures
• Removed duplicate test cases
• Added compressed texture format WEBGL_compressed_texture_s3tc with mipmap levels test cases

[krapnikkk]

@greggman
ProtocolError: Page.captureScreenshot timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.
The screenshot service in the test case seems to have timed out, causing the code check to fail.

[greggman]

I don't think this PR will actually work.

I put up an alternative PR here

https://github.com/greggman/twgl.js/compare/main...mipmap-upload?diff=split&w

With tests for both compressed and uncompressed textures which is more inline with twgl (compressed texture should not be a special case) and passing in blockWidth and blockHeight seems like something twgl should just take care of.

please take a look.

It works by you passing the exact amount of data needed for however many mip levels you want. So for example, if you have a 4x4 RGBA8 texture.

• if you pass (4*4*4) 64 bytes, you get 1 mip level
• if you pass (4*4*4 + 2*2*4) 80 bytes, you get 2 mip levels
• if you pass (4*4*4 + 2*2*4 + 1*1*4) 84 bytes, you get 3 mip levels

It works in blocks so similarly for a compressed texture that has a 4x4 block size where each block is 8 bytes. Assume we're making a 12x8 texture

• mip level 0 is 12x8 texels which is 3x2 blocks which is (3*2*8) 48 bytes
• mip level 1 is 6x4 texels which is 2x1 blocks which is (2*1*8) 16 bytes
• mip level 2 is 3x2 texels which is 1 block which is 8 bytes
• mip level 3 is 1x1 texels which is 1 block which is 8 bytes

so

• if you pass 48 bytes, you get 1 mip level
• if you pass 64 bytes, you get 2 mip levels
• if you pass 72 bytes, you get 3 mip levels
• if you pass 80 bytes, you get 4 mip levels

Note that it's a breaking change though because it guesses the number of mip levels you want uploaded based on the size of your data.

In other words, let's say you had a 4x4 RGBA8 texture. That needs 444 bytes (64 bytes) for mip level 0.

Before this change, passing 70 bytes of data was ok. It would just use the first 64 bytes. After this change, passing 70 bytes of data will generate an error because it's more than the first mip level (444 = 64 bytes) but it's not enough for the next mip level (224 16 bytes). I suspect almost no one is passing the wrong number of bytes but just to be safe I would bump the major version

[krapnikkk]

Yes, you are right. Your approach is more clear and clever.