WebGL必须要面对和克服的困难：

WebGL必须要面对和克服的困难：

• 因为OpenGL ES 2.0并没有被大多数的硬件平台所支持，所以将会导致很多设备无法运行WebGL。
• 因为OpenGL ES 2.0对JavaScript的依赖程度达到了100%，其利用JavaScript来处理应用程序的场景绘图，例如：1）计算场景中子父物体间的矩阵运算。2）Culling Calculating（计算不需要绘制的内容）。3）分类计算，用于处理透明对象等。4）计算场景所包含的所有动画数据。这些应用会因为JavaScript的计算瓶颈而受到不同程度的限制。
• 无法高效的利用Javascript处理Skinning，如果利用GPU的运算能力来处理，势必会占用过多GPU的资源，从而无法更好的协调其它效果，例如：Shadow mapping（绘制软边的阴影贴图算法）
• 借用一个例子来更进一步的剖析，例如：处理一个带有phong材质的物体，每一帧的渲染就接近多达10次以上的GL调用：

• 一、给Shader传递所包含的Matrix信息（通常1-5个Matrices）。
• 二、每个需要传递的Color参数信息都将占用一次GL调用，对于Phone材质而言，至少需要两次调用(Color &Shininess)。然而如果追求效果的最大化，那么可以把五个参数都用上（Emissive, Ambient,Diffuse,Specular, Shininess）一共产生五次GL调用。
• 三、处理定点坐标。
• 四、处理法线信息。
• 五、如果模型包含有贴图信息，那么还需要增加一次GL调用来传递UV信息。
• 六、最后再次执行GL调用完成对模型的绘制。
• 从上面的结果来看，最少也需要5次GL调用，最多可以达到14次。如果结合最终项目的需求以每秒30帧的频率来计算，其效率可想而知。

WebGL并没有积极的去解决数据导入问题。目前为止，仅仅可以利用IMG tags来嵌入材质信息，暂不支持DXT 图片压缩格式（而DXT已经被大多数的3D显卡硬件所支持）。暂无预处理技术，依然是在裸奔。在一个独立的File中不支持 CubeMaps（是一个以较低性能损耗来描绘静态物体对周围环境的反射效果的捷径）。除了利用JavaScript的数组以外，没有更好的方式传递几何信息。 以上的信息可以对当前WebGL的情况有个基本的了解，其实无论比较的结果如何，未来遇到实际问题时，都是要根据实际情况来选择适用的解决方案。在这里没有谁有压倒性的优势，都各有利弊。对于开发者来讲，追求效率的同时，可以在要求不够严格的情况下选择最易上手的工具，缩短开发周期。