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

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



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.

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