ANGLE_GLES20 in default Lwjgl3Launcher can cause mipmapped textures to render black

[CakeInvasion]

When using the default Lwjgl3Launcher generated by Gdx-liftoff, enabling configuration.setOpenGLEmulation(GLEmulation.ANGLE_GLES20, ...) can cause mipmapped non-square textures to render completely black.

configuration.setOpenGLEmulation(Lwjgl3ApplicationConfiguration.GLEmulation.ANGLE_GLES20, 0, 0);

This behavior is extremely confusing during development, because it looks like a LibGDX / mipmap bug, while it is actually ANGLE-specific.

Since Gdx-liftoff generates this line with comments suggesting it improves compatibility, it would be helpful to:

• document this behavior
• or add a stronger warning that ANGLE_GLES20 is meant for testing only and can differ from both desktop GL and real Android devices.

Steps to reproduce :

1. Create a new LibGDX project using Gdx-liftoff (LWJGL3)
2. Keep the default Lwjgl3Launcher configuration with ANGLE_GLES20 enabled
3. Load a mipmapped texture that is NOT a square (e.g. 512x128):
   new Texture(file, true)
   texture.setFilter(MipMapLinearLinear, Linear)
4. Render the texture (any draw size)
5. Result: the texture renders completely black on desktop
6. Disable ANGLE_GLES20 -> the same texture renders correctly
7. Using a square texture (e.g. 512x512) does NOT show this issue

Note: The same rectangular mipmapped texture renders correctly:

• on Android devices
• on desktop OpenGL without ANGLE

This took significant time to debug because the issue appears unrelated to the launcher configuration.

[tommyettinger]

I guess I'll look into this. I haven't used mipmaps pretty much at all, but I seem to recall they have their own situational issues on WebGL targets (GWT and TeaVM), unrelated to ANGLE. There's a significant lack of documentation about the ANGLE backend; @badlogic sent a PR in 2021 that was merged in 2022, see libgdx/libgdx#6672 , but there wasn't anything added to the wiki or almost any other documentation about it... to this day. The one place I found ANGLE mentioned was in the "Running from source" page, which mentions an option to enable ANGLE in tests. I don't know if the "official libgdx account" binaries are even used anymore, https://github.com/libgdx/gdx-angle-natives , since they were last updated 3 years ago. Nothing has been mentioned to my knowledge about mipmaps acting differently at all on ANGLE_GLES20, so you might be the first to discover this.

What OS are you using? If it's a Mac, what architecture is it? If it's Windows or Linux, what's your GPU or integrated graphics situation (are the drivers up-to-date, how recent is the graphics device, is it a laptop processor...)? I know at least iOS can be finicky about multiple-of-four sizes, where most OSes don't generally care. Mac might have similar uncommon constraints.

[CakeInvasion]

OS: Windows 11 x64
GPU: NVIDIA RTX 4060 (drivers up to date)
CPU: i5-13400F
Target: Desktop LWJGL3 (created with Gdx-liftoff)

Repro: In the default Lwjgl3Launcher generated by Gdx-liftoff, enabling:
configuration.setOpenGLEmulation(GLEmulation.ANGLE_GLES20, 0, 0);
causes mipmapped textures to render black on desktop (while the same code works fine with regular desktop GL).

Steps:

• New Liftoff project (LWJGL3)
• Keep ANGLE_GLES20 enabled
• Load mipmapped texture: new Texture(fileHandle, true)
• texture.setFilter(TextureFilter.MipMapLinearLinear, TextureFilter.Linear);
• batch.draw(texture, ...)

Notes:

• Texture is power-of-two but not square (e.g. 512×128 or 32×128).
• With ANGLE disabled (desktop GL), it renders normally.

This looks ANGLE-specific and very confusing during development because it resembles a “mipmap bug”.

Extra info (GL strings):
(I can paste glGetString(GL_VENDOR/GL_RENDERER/GL_VERSION) output if needed.)

I can also test ANGLE_GLES30 if you want (to see if it’s GLES2-specific).

[Frosty-J]

There's no such thing as ANGLE_GLES30, sadly. But yeah, this is a known issue: libgdx/libgdx#6909

If you want to use mipmapped textures, the options I see are to use square textures, remove ANGLE from your project (it's a separate dependency, so it just wastes space if unused), or make your own mipmapping system.

[tommyettinger]

It pretty much is a "mipmap bug", since it can be fixed by using square textures or by disabling mipmapping, and I'm not really sure this qualifies as a bug in Liftoff because no example projects it creates use mipmaps at all. It is definitely a quirk or flaw of the libGDX ANGLE backend code, and that really is under-documented. As Frosty-J found, this was reported over 3 years ago but no one commented on it then, likely because no one but its author ( @badlogic ) seems to understand how the ANGLE code works. Maybe @Berstanio knows something about it, since he's used lots of the native lower-level parts of libGDX, or @Tom-Ski because he's also worked on the native code a lot. I'm pinging people because I do think we need to document ANGLE bugs if we can't fix them, and I certainly can't make changes to the ANGLE backend from this repo. I think the ideal place for documenting the ANGLE backend is the wiki.

[Tom-Ski]

The angle impl is just a natives shim. Any issues really are gonna be directly at angle level, and not at libgdx level.

That said, this specific issue, is debatable if its an actual issue. Angle here is performing in line with the gles 2.0 specification.

From the spec:

OpenGL ES 2.0 supports non-power of two 2D textures, and cubemaps, with the caveat that mipmapping and texture wrap modes other than clamp to edge are not supported.

[tommyettinger]

@Tom-Ski it isn't that it's non-power of two, it's that it's non-square -- the dimensions are 512 (2 to the 9) by 128 (2 to the 7).

[Berstanio]

One low-hanging fruit to test could be, just updating ANGLE.
https://github.com/libgdx/gdx-angle-natives/blob/a0f1ac88dd53a286e296911520831c634c8a7fce/.github/workflows/linux-x64.yml#L9
It looks like the intention was to be regularly updated, but it seems to not work. A good thing to do would be probably, to just try to keep MetalANGLEKit and gdx-angle to the same ANGLE version. The release versions of ANGLE are confusing, but this was what was proposed back then on discord by @fgnm :

I think I've found a good way to schedule ANGLE updates, let me know if it sounds good. GitHub ANGLE repo has a bunch of branches tagged chromium/XXXX which I've found related to Chrome stable/beta releases: https://chromereleases.googleblog.com/search/label/Desktop%20Update ... You can notice that the latest stable Chrome version is 135.0.7049.84/.85, looking here https://www.chromium.org/developers/version-numbers/ The BUILD number is an ever-increasing number representing a point in time of the Chromium trunk.... So, for me it makes sense that the ANGLE branch chromium/7049_41 is the one used in the latest stable chrome version. Another confirm could be made by the latest beta which is set to 136.0.7103.25, I'm pretty confident it uses ANGLE from branch chromium/7103_3... It also seems that whenever a branch is used in any of Chrome releases it's tagged with chromium/XXXX_YYY... What do you think? Does it makes sense?

[Tom-Ski]

Doesn't seem to be any mipping related changes since our version. Need to attach rendering debugger in a test really to see whats going on.

[Tom-Ski]

Looks like angle is more strict about mipmap completeness. Will have a fix shortly

[Tom-Ski]

Should be fixed in libgdx/libgdx@d7ffdb3