[REQUEST] The implemented Angle support for Windows is not usable

[AlwinEsch]

Please confirm the following points:

• This question is NOT about the Android apps in the Play Store
• I have searched the project page to check if the question was already asked elsewhere

Topic

General Request

Your Request

We started on Kodi to update our addon https://github.com/xbmc/visualization.projectm to use newest version from here.

Unfortunately, there was a significant, tricky error in the Windows implementation for Angle via DirectX and unfortunately Kodi uses Direct3D 11 on Windows and not GL or Vulkan.

It was added with this request here #942 (also wrote a small note in it).

Thank you very much for the implementation, from testing it works fine in terms of code processing and implementation in Kodi is very good, just no GLES rendering via Angle under Windows!

Angle only allows GLES version 3.0 with DirectX and the 3.2 specified for Angle in projectM cannot be used (Angle with OpenGL directly under Windows supports GLES 3.2, only then would we not need Angle).

Here is the support list defined at https://github.com/google/angle:

	Direct3D 9	Direct3D 11	Desktop GL	GL ES	Vulkan	Metal
OpenGL ES 2.0	complete	complete	complete	complete	complete	complete
OpenGL ES 3.0		complete	complete	complete	complete	complete
OpenGL ES 3.1			complete	complete	complete
OpenGL ES 3.2			in progress	in progress	complete

If it were somehow possible to reduce the minimum GLES version in projectM to 3.0 it would be good, as support for higher versions will not be available under Angle in the foreseeable future.

[AlwinEsch]

I forgot to show the log output from projectM:

2026-05-08 04:44:47.134 T:19932    info <visualization.projectm>: ProjectMLib: [GladLoader] GLInfo  api="GLES" ver="3.0" profile="n/a" flags="n/a" glsl="OpenGL ES GLSL ES 3.00 (ANGLE 2.1.7258 git hash: d9fc4a372074)" vendor="Google Inc. (NVIDIA)" renderer="ANGLE (NVIDIA, NVIDIA GeForce RTX4070 (0x00002786) Direct3D11 vs_5_0 ps_5_0, D3D11-32.0.15.9597)" backend="EGL" user_resolver="no"
2026-05-08 04:44:47.134 T:19932   error <visualization.projectm>: ProjectMLib: [GladLoader] GL requirements check failed: Version too low: 3.0
2026-05-08 04:44:47.134 T:19932 critical <visualization.projectm>: Could not create projectM instance.

[kblaschke]

To support some Milkdrop rendering features, projectM requires GLES 3.2 (or core OpenGL 3.3). We'd probably either have to revert back to a fixed-function pipeline or at least rewrite a lot of code to support this older GLES version while not losing preset compatibility. Since OpenGL ES 3.2 is nowadays supported by 98%+ of all GLES-based devices, the potential overhead wasn't really worth supporting the older standard.

It's rather strange that Angle 3.2 isn't supported for D3D11, as I'd expect D3D11 to support more than the GLES 3.2 feature set. It's most probably not a first-class citizen in the Google world.

Features we use on top of GLES 3.0 currently include:

• Support for array-on-array syntax in shaders, used by some modern/advanced presets.
• Floating-point framebuffers, as we're using a single-channel, half-float (float16) texture to trace back warp movement for the Motion Vector Grid effect vertices.
• Vertex attribute binding.
• Improved texture sampler support, though I'm not sure if the actual features used are specific to GLES 3.1/3.2.

I could currently see two distinct ways of fixing the situation:

1. Add a separate render path, including specialized shaders, for GLES 3.0 to libprojectM and provide a build-time switch to select the GLES version (we already have a generic GLES switch). As stated above, this will probably require rewriting a major part of projectM's renderer and also the shader translator as well, with a possibility that some preset shaders may not work due to missing shading language features.
2. Wait until Google (or another contributor) adds GLES 3.2 support for Direct3D 11.

If 1. is implemented, it should be done in a really careful manner to not add too much additional code, as it needs to be maintained by our team in the future, e.g. any change in preset rendering will require more work. The master branch already contains a major refactor of the rendering code, encapsulating most GL calls in separate classes, so IMO this could be doable - sadly I personally won't have time to implement this in the foreseeable future.