On Sat, Feb 2, 2013 at 11:37 AM, Kornmann, Ralf <email@example.com> wrote:It is possible to generate D3D bytecode directly. There is even an assembler for this. Unfortunately this will not longer work as soon Angle would switch over to D3D 10+. To ensure that you don't mess with the bytecode anymore the compiled shaders are signed by the HLSL compiler and the runtime checks this.ArghlI have written a number of HLSL shaders and hardly run in compiler issues. In most cases problems were caused by me doing things wrong in the HLSL code. So I am not sure how many of the problems you noticed are caused by the ESSL to HLSL step.At least 3 of my WebGL demos have run into such issues, where a compile would take anything from 10 seconds to several minutes. The reaction of browsers to this problem is different. Chrome usually kills your context after about 11 seconds, and Firefox usually lets things run, but after about 15 seconds asks you if you want to kill the page since the JS is unresponsive.Anyway to ease the problem with the long compile times at least a bit it might be a good idea to add some kind of shader cache. This way it would a least faster the second time a user visit a page. Anything beyond this would most likely requires a custom shader container that can beside the pure GLSL code contains multiple binary shaders for different targets.There is a shader cache. But that doesn't really help that much because if you need to compile a serious amount of shaders (A typical high quality production has anything between 300 to 1000 different shaders) or if you run into a bunch of pathological cases (exceedingly likely with a large number of shaders) then the result is that a user never gets to the page. It'll lose context, or it'll ask him to kill the page, or he just leaves out of boredom to wait for stuff to happen. The typical 5ms or so compile time of GLSL via OpenGL is still way long. But the typical 100ms to 500ms compile time for GLSL via D3D pushes this beyond the point of breaking.