[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Minefield compositor issue...maybe?
- To: Vladimir Vukicevic <email@example.com>
- Subject: Re: [Public WebGL] Minefield compositor issue...maybe?
- From: Steve Baker <firstname.lastname@example.org>
- Date: Sat, 01 Jan 2011 20:56:08 -0600
- Cc: Ilmari Heikkinen <email@example.com>, 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=vbcyS CxuHmqhEgTR3/yiicStmIQ=; b=KVIqiJiFA2KGFEH1h7pEK4rxjFe1NGPJtKatU k1GAqPsbNymwYA8NcLbw/TIJz/VWbtf3KzErxLErTnzgrv7idVJpfZhSTLuNAstF ABos4sa9iW8Pw4uzG1tRZFpv5pwC9PmnaKXMz1Q+zHArRehswvJKN0oeT1RpgmKo mI8gWk=
- 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=kgI803wNO/ZeoHpMfZVMOegduFA3ZpYqxa71Cfa/OuOzte61TFgyagf5CYBUK DSTOGfBlFJLUN6xCqt/hVEQCC9oVBP7Jbgm15+V/670VQXehPy7m3aUWUZdSNDE7 e8NfGE8/D2m6UpGc8WC8MisqnSxpIgGdGwvyzkHqDhOc/4=
- In-reply-to: <1238876215.121292.1293917624339.JavaMail.email@example.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <1238876215.121292.1293917624339.JavaMail.firstname.lastname@example.org>
- Sender: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5
On 01/01/2011 03:33 PM, Vladimir Vukicevic wrote:
> ----- Original Message -----
>> 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.
> Is this a linux-specific problem? I haven't heard of this on Windows or OSX, and Linux does have the extra async interaction with the X server. Can you file a bug, if there isn't one already?
I think it's Linux only - but it's a little tough to pin down. It's
intermittent, dependent on loading and processor/GPU speed. Our EeePC
netbook is refusing to link our shaders (no error message...grrrrr!) and
the other two Windows machines we have here at home are both much faster
than our Linux box...so perhaps they don't exhibit the problem just
because they are quick enough.
My game is now pushing the performance envelope pretty hard - aside from
the WebGL load, we're piling on fancy HTML5 and CSS3 trickery, hitting
texture memory capacity on low-end machines, doing AJAX, sound effects
and background music. We make reasonable frame rates for the hardware
we're running on - but like most mainstream desktop games, there aren't
a whole lot of spare CPU cycles floating around! (Especially on low-end
The problem isn't that things go slow on low end machines - it's that
performance drops off so abruptly. We're hitting some kind of "death
I'm going to try piling on the pain on Windows machines and see if I can
trigger the same behavior there.
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: