Pixi.js: Comments in shaders source not respected

[erpy]

Commented shaders source code gets parsed as if not commented.

[englercj]

We should add support for comments for the precision addition part, but we should use the compiled program and not source parsing for other things IMO.

[erpy]

Parsing source code allows for rapid shader prototyping, which I believe is something you might want to keep. Maybe you could add a "source" field in the shaders object so you'd compile at load time and use the stripped, compiled version at runtime. (?!)

[GoodBoyDigital]

@englercj problem (which is maybe not a problem?) is that to compile a program we need to have a context, which we don't get access to until shader is used by the renderer. Solutions are:

1: We could use a little temp context to build shaders and then destroy them once we have the info.
- More accurate (will deal with stuff stripped out properties much in a much nicer way)
- Not sure how efficient it is to create / compile / delete

2: We parse the text of the shader as we currently do.
- opens us up to issues such as this
- clean as no gl context required to parse so it can be done instantly

Maybe option one is better as this should only happen on shader creation, so its not exactly a hot code..

Opinions welcome :D

[englercj]

Parsing source code allows for rapid shader prototyping, which I believe is something you might want to keep.

Not sure what you mean by this, we get all the reflection data in the compiled program. Same data from parsing the string, it just happens without a context.

Maybe option one is better as this should only happen on shader creation, so its not exactly a hot code..

Option 1 is definitely more accurate and less maintenance, I'm wondering if we can compile and cache the reflection data. So we destroy the program but cache the reflection data. That would reduce compilations to be a single time per shader source. Later when we compile the program using the actual context of the renderer we can actually store the compiled program next to the reflection data in this cache. So the cache is basically:

[shader-key]: {
    description: {}, // the reflection data for this program
    programs: { [context-id]: GLShader }, // the compiled programs for active contexts
}

Maybe that makes sense? Some helpers around clearing programs by context-id and other things would also be neat.

[GoodBoyDigital]

Yeap - we should definitely cache the reflection data.

Currently - The glShader lives inside the Shader (same way glTextures live in textures) This style works really nice!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.