@hermet @SergeyLebedkin
Thanks for reviewing. I’d like to confirm two points:

Binary shader support is an OpenGL 4.1+ feature, while our requirement is OpenGL 3. I added a helper function glIsProgramBinarySupportAvailable() in tvgGl.h to check runtime availability. This is the first runtime capability check in the project, so I’m not sure if this approach aligns with our design principles.

Although my MacBook Air supports OpenGL 4.1, it still returns GL_NUM_PROGRAM_BINARY_FORMATS = 0, meaning binary shader support isn’t available. I’m waiting for GPU access on a cloud platform to test the performance improvement in another environment.

While waiting, I’ll continue investigating the stroke rendering issue on the GL engine.

Binary shader support is an OpenGL 4.1+ feature, while our requirement is OpenGL 3. I added a helper function glIsProgramBinarySupportAvailable() in tvgGl.h to check runtime availability. This is the first runtime capability check in the project, so I’m not sure if this approach aligns with our design principles.

@wenjieshen Looks good, if the binary shaders doesn't working, we can fallback to a normal scenario.

@wenjieshen Could you please double-check this as well? a few systems might use this GL_ARB_get_program_binary for gl3 case. But please hold this, Maybe we can bump up the opengl dependency to v4 as the minimum requirement... If so, we can drop the v3 use-case.

@wenjieshen Could you please hold this? I think we can discuss the opengl dependency further. Maybe we can bump up the opengl dependency to v4 as the minimum requirement... If so, we can drop the v3 use-case.

@hermet Understood, I’ll pause the PR.
Agree that we should discuss the OpenGL dependency direction first. If we decide to move to 4.0+, we can remove the v3 fallback logic entirely.

Understood, I’ll pause the PR.

@wenjieshen I mean we can hold support v3 for binary shaders. I didn't mean hold this PR. Please go proceed. :) Thanks.

Thank you for the suggestion. I’ve added a validation header to the binary file.

After corrupting a file (as shown in the screenshot above), the cache successfully detected the issue and removed the file.

However, identifying and removing redundant files is still challenging. At the moment, I don’t have a good way to determine which files are no longer needed. I’d prefer to address this together with the version that stores the mono cache file, so both features can be handled cleanly in the same update.

@wenjieshen Maybe we can consider removing deprecated older shader files...

What do you think if we use like: tvg_glshader_{TVG_VERSION}.bin

The binary format could have three sections - [Tag(2byte) + Hash(4 bytes) + Binary Shader] The tag notify us that file is thorvg gl shader file. We can have a specific value for this. The binary shader is stated with offset 6 bytes.

cache = load(tvg_glshader_{TVG_VERSION}  //see: THORVG_VERSION_NUMBER()
verify cache file is valid with the tag. 
use shader if the cache hash value equals current shader hash

If the current version shader binary is existed but the hash is different, we can remove the old and update with the latest.

The file IO is expensive relatively. Current shaders are more than 10, it needs a consideration before pushing this. That would be the best if we can introduce the one single binary form....

1. Verifying Shaders

• Current: Use a Hash & ThorVG version
• After: Use the ThorVG version only. ie) CACHE_FOLDER/thorvg/gl_shaders_VERSION_INFO.bin
• Later we can introduce a binary shader feature toggle option.
• • On dev, we can disable the binary shader, but we can enable it manually when necessary.
• • Enable the binary shader feature with the official release binary.

2. Lazy Loading or Immediate Loading

• Lazy Loading needs to hold the binary shader memory, We need to confirm the total size of the memory first.

1. Verifying Shaders

• Current: Use a Hash & ThorVG version
• After: Use the ThorVG version only. ie) CACHE_FOLDER/thorvg/gl_shaders_VERSION_INFO.bin
• Later we can introduce a binary shader feature toggle option.
• • On dev, we can disable the binary shader, but we can enable it manually when necessary.
• • Enable the binary shader feature with the official release binary.

2. Lazy Loading or Immediate Loading

• Lazy Loading needs to hold the binary shader memory, We need to confirm the total size of the memory first.

@hermet
I understand. Thanks for the suggestion.
We can roll back this version if the loading efficiency gain doesn’t justify the additional memory overhead. On average, loading a single discrete shader takes 0.59 ms, while loading the combined binary file (containing all shaders) takes 0.87 ms. Since each example may require between 17 and 89 shaders, the unified loading approach can improve total loading performance by roughly 11× to 60×, depending on how many shaders are needed.

Memory Usage

After combining the binary shader files, the maximum additional memory usage observed across all examples is 857.21 KB.

Shader Loading Time (per example)

• Mean (Average): 0.867 ms
• Median (50th Percentile): 0.877 ms
• Standard Deviation: 0.175 ms
• Variance: 0.031
• Minimum: 0.183 ms (Fastest load time — Animation.exe)
• Maximum: 1.322 ms (Slowest load time — StrokeLine.exe)

Accumulated Write Time(per example)

• Blending.exe: $10.897$ ms
• Accessor.exe: $4.334$ ms
• SceneEffects.exe: $1.415$ ms
• Duplicate.exe: $0.455$ ms
• EffectDropShadow.exe: $0.343$ ms

Shader Writing Time (per shader)

• Mean (Average): 0.203 ms
• Median (50th Percentile): 0.174 ms
• Standard Deviation: 0.090 ms
• Variance: 0.008
• Minimum: 0.126 ms (Fastest write time)
• Maximum: 0.670 ms (Slowest write time)