What I wrote in part 1) of https://savannah.nongnu.org/bugs/?42327#comment1 was not entirely correct: the OpenGL shader language supports indexed buffers, and our new rendering engine can make use of it. However, there can only be one index for both vertex coordinates and colors (and for texture coordinates as well). Thus, when using 'vertex' color, all vertices have to be specified for all elements (coords as well as colors). This also applies to 'element' color, which is a pyFormex color mode not supported by GLSL, and therefore expanded to 'vertex' color.

However, in 'single' or 'no' color mode, the index can be used, and it would be sufficient to store the common vertices of the elements only once, and use a proper index. This would also work for a 'node' color mode, which we currently do not have in pyFormex, but which might be a useful addition (now that we have the Field class) for rendering field data (e.g. during post-processing).

The WebGL exporter actually exports the actors from the rendered scene, not the Geometry you created. For the reasons explained above, these actors may contain more vertices than the original Geometry that was rendered, and colors will have been multiplexed likewise. Because of this, the created .pgf files for WebGL rendering may have quite different contents than when you save the Geometry in PGF format yourself.

An extra note to my previous comment, part 1) :
The WebGL application (like the OpenGL shaders) only draws triangles. Thus each quad is split into two triangles for rendering purposes.

1) when exporting the scene the mesh in the pgf.gz includes ALL ELEM NODES, like a Formex (see attached example)
2) in order to draw a nodal field (with a single value at every node) you could just give mesh.ncoords() values.
Why should you give val[obj.nelems]  ? This last case is the most
general and it would only be needed if a mesh would be
made of 'unconnected' faces colors, with
sharp color changes of adjacent edges.

Or maybe there is a reason for this.