[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Minefield compositor issue...maybe?
- To: Ilmari Heikkinen <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Minefield compositor issue...maybe?
- From: Steve Baker <email@example.com>
- Date: Sat, 01 Jan 2011 18:57:19 -0600
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sjbaker.org; bh=WH3bR dzXPDtJa+mVRLp4W96Tsd4=; b=rmEtGUWWqhua/uBq1qUjoAxkGGZ6FG1DQk5YH Uj2LzEPVtUyJFQ0x4xiWmhFH4CA1JOasbqf3cX0hY6oMGpT5S4lBDLafgn1540X4 c2ts+NdqBaxPCy/DOK9pT6B1T+D0c+KhSPBuoRGNuoX6Hcuz5RTSDJXxQtkjTu82 2hGHAE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sjbaker.org; b=fJUFYIuEWQhulXZi8amN29gDFAqH8cRSHXQmKhG/W7HWuXopJPSAUvWTGFA9k pT4eq7WvydAeMPMiELiyzgpC5EEkbls/a/WIUXfSjgV+ruurkLdvXr39oLieTTYa pc1Hct1PCed2GtYicoArSHgOOna/e6gc1hcbCLIVQNe7mI=
- In-reply-to: <AANLkTi=g9y_y1Gdo5Ak1=6PR_97+T23Ya2TfG=gMVpQQ@mail.gmail.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4D1EC1D8.email@example.com> <AANLkTi=g9y_y1Gdo5Ak1=6PR_97+T23Ya2TfG=gMVpQQ@mail.gmail.com>
- Sender: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5
On 01/01/2011 01:39 PM, Ilmari Heikkinen wrote:
> 2011/1/1 Steve Baker <email@example.com>:
>> 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
>> Is this even possible?
>> Eventually, the game graphics stop being updated at all - but I can tell
> 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
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.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: