[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL performance...seems like I have no hardware acceleration?!?



Chris Marrin wrote:
> On May 26, 2010, at 7:18 PM, Steve Baker wrote
>> I've been thinking about porting some of my old OpenGL games over to
>> WebGL - and sticking them on my website for free to help to promote
>> WebGL (which is a noble and important cause!) and I'm seeing some weird
>> performance issues.  (I've been an OpenGL programmer since it was
>> pronounced "IrisGL" - and I work in the games industry as a senior
>> graphics programmer - so I'm not entirely clueless).
>>
>> Now, I expect JavaScript to be slow - but we're using a real, hardware
>> graphics card - right? - so my expectation would be that if I push as
>> much functionality onto the GPU as possible and keep things simple on
>> the CPU/JavaScript side, I should be able to get decent frame rates.
>>
>> To test, I wrote a really minimal application - it sets up matrices, it
>> clears the screen and renders a few simple objects and uses
>> setTimeout("draw()",1) to try to get the best framerate I can.  I'm
>> getting like 10Hz. :-(
>>
>> Since I don't know whether my JavaScript is somehow doing something
>> nasty, I tossed out all of the 3D rendering and did nothing but clear
>> the screen.  Doing this test at a number of different canvas sizes, I get:
>>
>> 1280x1024: 15Hz.
>> 800x600 : 35Hz.
>> 200x200 : 90Hz.
>> 100x100 : 180Hz.
>>   8x8   : 180Hz.
>>
>> Commenting out the clear-screen and doing no OpenGL calls at all in my
>> main loop still gets me 180Hz - so I guess I'm CPU-limited at that frame
>> rate.
>>     
> Can you post a sample so I can try it in Safari? Maybe we can also see where the bottlenecks are. I agree 15 Hz is shocking for a simple scene. The Many Spheres Deep demo on the site renders over 100,000 triangles per scene in 64 objects and it easily makes 60fps on my Macbook Pro.
>   
The code that I used to produce those numbers ended up producing the
exact same numbers with nothing more than a glClear on both color buffer
plus Z - with a 1ms "setTimeout" to retrigger the 'draw()' call !  This
isn't about numbers of triangles or numbers of objects or even number of
pixels drawn - it's purely about the size of the 3D canvas area.  It is
evidently the final compositing stage that's the killer here - and on my
Linux and Windows PC's with Minefield, the cost of doing that is roughly
5Mpixels/second on a 2.8GHz CPU - more or less irrespective of the
graphics card I'm using.   If I factor out the time for doing the
compositing, I can draw an ungodly number of triangles - comparable to a
native C++ application running full-up OpenGL - and even do a ton of
fill-rate-intensive stuff with really complex shaders.  The performance
for complex rendering hardly changes between that and just clearing the
screen!

So it's pretty clear that the compositor is a horrible bottleneck under
FireFox and Chrome.  We're told there are plans afoot to fix the
compositor to be OpenGL-based and then (from what I can tell) we'll have
JavaScript performance being the only bottleneck compared to a full
native C++ application...and that's pretty impressive!

If Safari already has hardware compositing - then this test should
already run fast.

As I said before, the trick to getting things to run fast in WebGL is
going to be to move as much of the work into the GPU and out to the
server as possible so that JavaScript has the least possible work to do.

  -- Steve

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: