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

Re: [Public WebGL] Minefield compositor issue...maybe?

On 01/01/2011 01:39 PM, Ilmari Heikkinen wrote:
> 2011/1/1 Steve Baker <steve@sjbaker.org>:
>> I'm seeing a bunch of odd symptoms with the last few Minefield nightlies
>> on Linux 64bit.
>> Firstly, I suspect a memory leak or something because repeatedly
>> reloading my game causes it to start running more and more slowly.
>> Exiting & restarting the browser fixes that.
>> But more weirdly, the frame rate that I'm seeing in software (using
>> essentially the same code that many of the demos use to measure it) is
>> actually getting FASTER while the displayed graphics are going slower!?!
>> My best guess is that the compositor has somehow decided not to bother
>> recompositing the page quite so often - so the image LOOKS jerky...but
>> the WebGL rendering loop now has more time available (because we're
>> doing less compositing) and actually speeds up - producing a higher FPS
>> reading!
>> Is this even possible?
>> Eventually, the game graphics stop being updated at all - but I can tell
>> (by monitoring server activity) that the Javascript is still looping.
> Calling readPixels at the end of the frame might help. At least
> getImageData helps for 2D canvas, which suffers from a similar
> problem. I guess Minefield is doing the actual drawing async from the
> timeout handlers, the API calls just push commands in the command
> pipe. And if it can't clear out the command pipe before the next
> timeout, the size of the command pipe keeps growing and growing until
> it hangs the renderer.
Yeah - that would be exactly the kind of thing I'm seeing.  The
Javascript code is stuffing a bunch of stuff into the GPU command queue,
then finishing up with a 16ms timeout (usually, this gets me a ~30Hz
frame rate and leaves the roughly CPU 50% idle)...but if compositing is
asynchronous then it could easily be that the GPU doesn't come free
until the timeout expires and I start drawing again.

Doing a gl.readPixels(0,0,1,1,gl.RGBA,gl.UNSIGNED_BYTE,buffer);

...reduced my frame rate quite a bit...but it didn't help.

Increasing the setTimeout() from 16ms to 33ms seems to largely avoid the
problem (which seems to happen most on low-end machines) - but on high
end systems, it just clobbers my frame rate unnecessarily.

  -- 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: