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

Re: [Public WebGL] frame timing and continous scaling

Investigating this issue a bit more I came to some conclusions. I've also extended the test tool to measure/display both interframe time (grey) and intraframe time (red) and added options for different synchronizing methods. The conclusions first, the observational evidence after.
Chrome on windows

Here is where we want to be (ideally). This is a rising JS load test (no webgl) in chrome which nicely shows how well behaved this can be (and what we want to get out of UAs).

Inline image 1

Of course if we toggle to a WebGL load test without any synchronization it looks like this, no indication whatsoever when we're going to drive into a wall.

Inline image 2

Unfortunately, the same is true in chrome when calling gl.finish as well:

Inline image 3

I have tried various other methods (flush, texImage2D, bufferData) and they don't have any appreciatable effect. The only two that do have an effect is readPixels and getError. Get error is not very helpful however.

Inline image 4

So the last command to synchronize things that can work is readPixels, and low and behold, it does work as intended. However this costs us roughly 30% of performance.

Inline image 7

Internet Explorer

Internet explorer doesn't implement even frame division stepping. So at a rising load and no finish no attempt at FPS stepping is evident (other than the 60fps clamping).

Inline image 8

And like in Chrome, gl.finish doesn't seem to do a whole lot (though it does a little more than in Chrome).

Inline image 9

Also like in Chrome, gl.readPixels is about the only solution left:

Inline image 10

Firefox on windows

Firefox also doesn't implement even frame division stepping. And like IE, after the 60fps clamping, interframe times just keep rising. Unlike chrome, firefox seems to spend a considerable amount of time in JS for a few simple loops.
Inline image 11

Here however readPixels seriously mucks things up.

Inline image 12

Luckily, gl.finish is much better behaved:

Inline image 13

I have run these tests on Linux so far also comparing UAs, and have arrived at similar results. It's possible this is different on OSX, and it might also depend on the GPU.