P4
Decora's JSL generation based shaders contain a lot of duplicated code, which leads to a bigger runtime jar, even when compressed.
This ticket is about GLSL shaders because their plain text deployment model can actually be taken advantage of, to remove all this duplication, whereas i'm not sure it's possible with the complied HLSL's obj files.
I also presume that this duplication also slows down compiling the shader, but since it's only done once in decora AFAICT, it might not be that big of a problem.
For example: the Blend effect is compiled into 19 different shaders, one for each blending mode. If you look at them you see they actually differ on only one line - the blending mode method to call for this specific shader - and contain the code for the 19 different possible modes even though they only use one.
There are two ways to reduce this: first you can obviously modifiy each glsl manually and remove what is not needed. Secondly, you can create a kind of "include" facility à la C preprocessor, where you would define the 19 methods in a "global" way. Since the shaders are sent to JOGL as plain strings, they can be processed at runtime beforehand, with minimal costs (plus it's only done once as i said) to allow the blending methods to be concatenated to the only different line we talked about. (Note that this would just solve the deployment size problem, not the time to compile the shader, since this is recreating the shaders as they currently exist)
I've tested this rapidly.
The total combined size of those blend shaders is 64.4k; doing either method described here brings down the size to 4.13k which is approximately 1/16th of the original.
Uncompressed it reduces the total opengl decora code by more than 25%, in a compressed jar, the reduction is about 15k; all in all this is decent for 10 minutes work without knowing the internals.
The unrolled shaders can also be generated at runtime which could theoretically allow the radius limits to be expanded. In practice however, since it would only be on the jogl/rsl+opengl backends and not the others, i'm not sure it's even worth considering.
This ticket is about GLSL shaders because their plain text deployment model can actually be taken advantage of, to remove all this duplication, whereas i'm not sure it's possible with the complied HLSL's obj files.
I also presume that this duplication also slows down compiling the shader, but since it's only done once in decora AFAICT, it might not be that big of a problem.
For example: the Blend effect is compiled into 19 different shaders, one for each blending mode. If you look at them you see they actually differ on only one line - the blending mode method to call for this specific shader - and contain the code for the 19 different possible modes even though they only use one.
There are two ways to reduce this: first you can obviously modifiy each glsl manually and remove what is not needed. Secondly, you can create a kind of "include" facility à la C preprocessor, where you would define the 19 methods in a "global" way. Since the shaders are sent to JOGL as plain strings, they can be processed at runtime beforehand, with minimal costs (plus it's only done once as i said) to allow the blending methods to be concatenated to the only different line we talked about. (Note that this would just solve the deployment size problem, not the time to compile the shader, since this is recreating the shaders as they currently exist)
I've tested this rapidly.
The total combined size of those blend shaders is 64.4k; doing either method described here brings down the size to 4.13k which is approximately 1/16th of the original.
Uncompressed it reduces the total opengl decora code by more than 25%, in a compressed jar, the reduction is about 15k; all in all this is decent for 10 minutes work without knowing the internals.
The unrolled shaders can also be generated at runtime which could theoretically allow the radius limits to be expanded. In practice however, since it would only be on the jogl/rsl+opengl backends and not the others, i'm not sure it's even worth considering.