EWGL-matrices   1 comment

Hey there,

As many may already know, I’ve started writing EWGL-Matrices. It is the fastest 4×4 matrix library around ;). Although it is the fastest around, it still can be increased in speed by removing the object matrix and just use methods like mjs does. And Even that library could get faster if needed. (I am thinking of the way assembly calculates) . So we’re not even close to our end goal but we are getting there. But for the moment I am going to talk what EWGL-matrices does do to increase speed.

But First some comments. Everything We did to increase the speed is completely compliant with the JavaScript spec. So every Browser supporting WebglFloatArray and has a decent JavaScript interpreter will have no troubles with EWGL-matrices. Secondly, I want to thank everyone who helped me create this Library. It couldn’t beat that ridiculous fast mjs in even 1 function. Thirdly, Vlad really helped to bring things even faster because of his ridiculous fast mjs library. Hehe, I stole some ideas from him.

EWGL-matrices lowers the burden on creating a new matrix by only having one newly created element in its initialization, elements. All it’s methods are in the prototype of that matrix object. But why would that be so important?? Well Every time you duplicate a matrix it needs to create a new matrix. That is why a new matrix needs to be fast.

But why did I choose to work with my elements closed into a WebglFloatArray and not into an array like Everyone. Well that is only after some tests done of course. When I first tested an WebglFloatArray against an Array, It was a lot slower. (begin days of webgl) But then After a few months I noticed a shift, WebglFloatArray was getting at the speed of arrays or is now even faster than arrays. That was 1 factor of course but there is still another factor that made me decide on WebglFloatArray. That was the fact that everyone uses New WebglFloatArray for every matrix sent. Which is not only not needed anymore thanks to the WebglFloatArray in the matrix but it also helps the garbage collecting that doesn’t need to collect all these empty WebglFloatArray which also decreases the speed although less measurable (so you need to believe me on my word for that. Sorry about that). So WebglFloatArray is not slower then arrays and it doesn’t need conversions and It doesn’t waste GC resources. Enough reasons I guess to use WebglFloatArray.

But that is not all to it because there are other libraries that do the same but don’t achieve the same speed. Another thing is using no loops and no functions in our methods because we don’t need them. No functions means no closures created and no everything around it which is again an speed increase. No loops are needed because we always know for sure there are 16 elements in the matrix (4×4= 16 ;) ). So everything is written out as much as possible.

And last but not least, There is a the fact that caching also exists. This is of course possible because of javascript taking references of objects. And because a saving a reference and using that is faster than looking the same thing up 2. So we use a lot of caching in EWGL-matrices.

Well There is more of course like using ternary statements over if statements and using || and && over ternary statements but this was about everything that made it fast.

But I said, We could make it even faster, So why didn’t We. I wanted a fast matrix object oriented library, So just for my connivance isn’t it. But that doesn’t mean I am going to stop now. But everyone knows by now that mjs can become faster. This will be my next project if I can find time. And then We will go to the next matrix library called EWGL-amjs (A stands for assembly) . Of course again based on mjs (I really like that library, don’t I) . But that is still something that is only a idea I still need to really test it.
I hope Now to see better library for webgl. And many more improvements based on this article.

Ps: I was really queit lately because I found a job but It won’t better soon so I can only hope It will improve. I’ve written this post becuase many couldn’t believe how I could achieve this speed.

Posted March 25, 2010 by ewgl in webGL

Tagged with , ,

matrices   1 comment

hello there again,

It has been a while but now I can finally present you guys something that works. It is a matrix library that is somewhat fast (actually it isn’t as fast in google chrome as I hoped) but it still will be 2 to 3 times faster than Sylvester for nearly every function in there. And a lot of functions in there.

Minefield is another story it seems to keep close to mjs which seems to beat Sylvester at least a 100 fold so that is not something that is bad my guess.

The 2 libraries to test against are Sylvester and mjs (the most used one and the fastest one).

testsuite: testsuite can take ten minutes or so to complete

sorry no docs or anything just a quick update on a faster matrix library

suggestions or other matrix libraries to test against are greatly appreciated

Posted February 19, 2010 by ewgl in webGL

uniforms   6 comments

Hey there,
I am still not a regular blogger but I hope I can change that. So now I am going to talk about uniforms. As many know, uniform variables are used to specify things that change for each VBO and not for each vertex. That means many uniform variables are normally used in a shader. So that is why I started researching uniforms. First thing I noticed although everyone saved the location of an attribute but not so of the uniforms. This seemed a weird phenomena so I started looking at the openGL ES draft.

quote from openGL ES draft:

“The actual locations assigned to uniform variables are not known until the program object is linked successfully. After linking has occurred, the command glGetUniformLocation can be used to obtain the location of a uniform variable. This location value can then be passed to glUniform to set the value of the uniform variable or to glGetUniform in order to query the current value of the uniform variable. After a program object has been linked successfully, the index values for uniform variables remain fixed until the next link command occurs.Uniform variable locations and values can only be queried after a link if the link was successful.”

So now I say to everyone using shaders, don’t do such costly operations as getting the location of uniforms in your draw function. It is better to do it only when shaderprograms get added. This would be a one time cost that makes sure that everything in your draw function get faster.

But then of course most people want to play safe against typo’s so you will need to know if a uniform variable is actually in the shader. because some browsers doesn’t show anything different about whether it has found the location or not as it shows only “WebGLUniformLocation”.

This solves that:

var uniformlocation,uniform;
uniformlocation = gl.getUniformLocation(shaderProgram, NameOfUniform);
if (uniformlocation !== -1){
uniform = gl.getUniform(shaderProgram, uniformlocation);
} else {
uniform = null;
}
if (uniform === null){
alert("uniform " + NameOfUniform + " doesn't exist in shaders");
}

So I hope that everyone will use a store uniform locations in a variable to allow even more faster webgl demos. I hope to see you readers for the next blogpost.

Posted January 11, 2010 by ewgl in webGL

new WebGLFloatArray overhead   6 comments

I did some research on “new WebGLFloatArray”. As it is used (in every example), everytime a uniform matrix is updated. And of course I came to the conclusion that it uses too much memory. Here is an example from learningwebgl.

function setMatrixUniforms()
{
var pUniform = gl.getUniformLocation(shaderProgram, "uPMatrix");
gl.uniformMatrix4fv(pUniform, false, new WebGLFloatArray(pMatrix.flatten()));
var mvUniform = gl.getUniformLocation(shaderProgram, "uMVMatrix");
gl.uniformMatrix4fv(mvUniform, false, new WebGLFloatArray(mvMatrix.flatten()));
}

It is just too slow and uses too much memory usage. This way really uses too much memory at once,also creating a new WebGLFloatArray is time-consuming but I found something interesting in the webGL specs.

5.13.3.9 WebGLFloatArray

WebGLFloatArray represents an array of 32-bit floating point values.

WebGLFloatArray has an element size of 4 bytes.

[
    Constructor(in unsigned long length),
    Constructor(in WebGLFloatArray array),
    Constructor(in sequence<float> array),
    Constructor(in WebGLArrayBuffer buffer,
                [Optional] in unsigned long byteOffset, [Optional] in unsigned long length)
]
interface WebGLFloatArray : WebGLArray {
    [IndexGetter] float get(in unsigned long index);
    [IndexSetter] void set(in unsigned long index, in float value);
    void set(in WebGLFloatArray array, [Optional] in unsigned long offset);
    void set(in sequence<float> array, [Optional] in unsigned long offset);
};

It seems like a WebGLFloatArray has a method set which of course sets the values but it doesn’t change the length of the WebGLFloatArray. And it doesn’t return itself which would be easy for chaining and less code lines.

So the upper function can be changed towards


// this just need to be an array of 16 elements passed in the new WebGLFloatArray
var FloatArray = new WebGLFloatArray([1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]);
function setMatrixUniforms()
{
var pUniform = gl.getUniformLocation(shaderProgram, "uPMatrix");
//Because it doesn't return itself it needs an extra line of code
FloatArray.set(pMatrix.flatten());
gl.uniformMatrix4fv(pUniform, false, FloatArray);

var mvUniform = gl.getUniformLocation(shaderProgram, "uMVMatrix");
//Because it doesn't return itself it needs an extra line of code
FloatArray.set(mvMatrix.flatten());
gl.uniformMatrix4fv(mvUniform, false, new WebGLFloatArray(FloatArray);
}

Unluckily for us, as of today, minefield is not able to use this yet as it has not been implemented fully in minefield.

Posted December 20, 2009 by ewgl in webGL

Tagged with , ,

Hello world!   Leave a comment

this is a blog meant for webgl additions and for lessons around EWGL.

Posted December 7, 2009 by ewgl in Uncategorized

Tagged with

Follow

Get every new post delivered to your Inbox.