cpu at 100%

Even when I’m running the simplest examples of webGL like this:
http://learningwebgl.com/lessons/lesson01/index.html
my cpu reaches 100% load at the moment the page loads.
I’m using Mozilla Firefox 3.7a1pre at Windows XP 32-bit with SP3 and hardware:
cpu: AMD Turion 64 Mobile Technology MT-32
graphics: GeForce Go 7300 256MB with driver 6.14.11.7948
memory: 1,5 GB
Where’s the problem?

It’s running at 30% CPU here on Intel Core 2 Quad (2.5 Ghz) with Geforce 9800 Pro.
The reason is probably because there is a call

setInterval(drawScene, 15);

That means it tries to redraw the scene every 15 ms or with 66 frames per second. Each frame it creates two JavaScript arrays with vertex data. Arrays in JavaScript are actually HashMaps, which means they are slow when using them just as arrays. These two “arrays” are converted into an CanvasFloatArray (true array) and are then uploaded to the graphics card into newly created VertexBufferObjects.

That’s just inefficient code :wink:
You could try to create each VBO just once and reuse it every frame.

However, when using an native compiled application (C++, …) this would be much faster.

Yup, Coolcat’s right – the code’s not very efficient. It’s a first lesson in WebGL and I figured simplicity was more important than speed :slight_smile:

In a later lesson, once I’ve started using JS objects to represent objects in the scene, then things should be a bit faster…

I can’t find the reference for CanvasFloatArray(). What is the return type of this function? Maybe we use this type rather than js arrays and skip casting those type due to CanvasFloatArray?

CanvasFloatArray is a class rather than a function, and, as far as I can make out from the Firefox source, it doesn’t have any useful methods. From http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/canvas/nsICanvasRenderingContextWebGL.idl#69, I’ve found:

interface nsICanvasFloatArray : nsICanvasArray
{
};

and


interface nsICanvasArray : nsISupports
{
   attribute unsigned long length;
 
   [noscript, notxpcom] unsigned long nativeType();
   [noscript, notxpcom] voidPtr nativePointer();
   [noscript, notxpcom] unsigned long nativeSize();
   [noscript, notxpcom] unsigned long nativeElementSize();
   [noscript, notxpcom] unsigned long nativeCount();
};

…which would seem to imply that it’s an almost completely opaque type from the JavaScript side (if I’m interpreting those “noscript” flags correctly). And running the following code:

      for (var f in CanvasFloatArray([]))
        alert(f);

Showed only one attribute, the length one that you’d expect from the IDL.

So, nice idea but I don’t think it’ll work, at least in current versions of WebGL.

class of course, my mistake. thanks for the answers