Chrome Developer Tools Timeline Frame Rate and WebGL

[Helmut Emmelmann]

Hello,

I am trying to improve performance of my webgl lib/app using the chrome developer tools timeline.

The attached screen shot of the timeline shows frame times of about 16-18ms and some of about 32-34ms

To me the prolonged frame times of about 32ms seem to indicate dropped frames. 

On the other hand the rAF callback seems to be called about every 17ms (otherwise my app complains

and degrades to simpler shaders and a smaller canvas). 

So my first question is:

    Is this measurement and its interpreation correct,  is there indeed a problem with dropped frames ?

If the answer is true, then the question is why. To me the timeline shows some GPU activity, but there 

seems plenty of room. The rAF call back seems not shown most of the time, because it is too fast.

Also I don´t see anything else, that might cause the dropped frames.

My test page is http://taccgl.org/blog/HTMLpages-with-3D-objects.html

using browser Version 68.0.3417.0 (Offizieller Build) canary (64-Bit) on a 4k display with 60 Hz

Thank you very much,

Helmut

[Helmut Emmelmann]

Here is the missing screen shot.

[Ken Russell]

Hi Helmut,

I profiled http://taccgl.org/blog/HTMLpages-with-3D-objects.html with Chrome's DevTools and it's clear that you're calling glGetError repeatedly, including during every frame and during buffer data uploads. This is a synchronous round-trip to the GPU and is disproportionately expensive on Chrome. If you stop calling it you'll probably eliminate these hiccups.

-Ken

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Helmut Emmelmann]

Am Donnerstag, 3. Mai 2018 00:39:20 UTC+2 schrieb Kenneth Russell:

Hi Helmut,

I profiled http://taccgl.org/blog/HTMLpages-with-3D-objects.html with Chrome's DevTools and it's clear that you're calling glGetError repeatedly,

Hi Ken, 

thanks a lot for profiling.  The options http://www.taccgl.org/blog/HTMLpages-with-3D-objects.html?prod=t&dbg=t&nodrawerrcheck=t&nosetuperrcheck=t disable all the glGetError calls. Unfortunately  the timeline attached still shows the dropped frames.

including during every frame and during buffer data uploads.

The application performs buffer uploads only during start up. The loop itself just has a draw calls. 

Without the nodrawerrcheck option it performs a glGetError as the first call of the loop for every frame. This is important since I need to show some alternative content in case of problems with

the webgl. The idea is to use the lib on landing pages that should run correctly on almost any device, although it is ok to disable webgl on some devices.

However, I probably could do a glGetError call every 10th frame or every second.

 

This is a synchronous round-trip to the GPU and is disproportionately expensive on Chrome. If you stop calling it you'll probably eliminate these hiccups.

Unfortunately the hiccups do not go away when disabeling the glGetError calls. 

Helmut

 

-Ken

[Jaume Sánchez]

It might be that your canvas covers the whole screen, so even though the calls are relatively lightweight -from WebGL's perspective- you're forcing Blink to resubmit the whole page every frame. And you said it's a 4K display...

[Helmut Emmelmann]

Am Donnerstag, 3. Mai 2018 21:48:18 UTC+2 schrieb Jaume Sánchez:

It might be that your canvas covers the whole screen, so even though the calls are relatively lightweight -from WebGL's perspective- you're forcing Blink to resubmit the whole page every frame. And you said it's a 4K display...

Yes it is indeed a rather demanding application for some GPUs, because it tries to run full screen / full window

(for applications like full page backgrounds or parallax scrolling designs as on http://taccgl.org). 

If the rAF call back rate drops, however, my lib uses simpler shaders and switches to a smaller canvas.

Currently I am, however, debugging on a good gpu, that can do 4k nicely. The FPU meter of chrome shows 59.9 and the rAF call back is called at 60 Hz. 

Yet the timeline of developer tools shows many >32ms frames.  

So I dont know for sure, if there is a problem as the timeline suggests or if it runs fine as the FPU meter says.

The timeline also suggests that CPU and GPU have plenty of room.

If it runs it on slower GPUs, then as usual the timeline shows a crowded GPU and the rAF callback is throtteling finally causing dropped frames.