[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Ambiguity and Non-deterministicness in the WebGL Spec
- To: Mark Callow <email@example.com>
- Subject: Re: [Public WebGL] Ambiguity and Non-deterministicness in the WebGL Spec
- From: Steve Baker <firstname.lastname@example.org>
- Date: Sun, 12 Dec 2010 23:18:53 -0600
- Cc: "Gregg Tavares (wrk)" <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=I3rC+ Rl8B5n8WCNnYKVZ6WG+fSM=; b=cdooTBEwMYMXcxFN58+UJimOPk+1KoJ6MBdgP YXhFZCdmIe6ROt9UsxWZpBXjhbts2zbadNtUVRcJAmPA8Ite7/+u6LeANPqwl34M I5ZwDWhibwaq5XWlDCGzvMyqflXPfjWPjvyy7v7ykvkzfGbcDjFX3XuEWDdXPoc5 HpUDiA=
- 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=UALvxAtqCz1+Odywj9dTRLWoIGrK8+5gJ3BHcBNthL/EdhDDABTl9SPWW1v2I 7++hOYXsAOrlzTehIxQuNRyIZHptWIBzWnRw51WW4nazuxWydD7rK27iRuXEWz6u U0MhYzc5R0KNzCNHLOyb/NSJrcwGdQNL8rdc0JqRQ1fdfk=
- In-reply-to: <4D058A97.email@example.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <AANLkTimA1yWqLNpQ_qEQ67tJ9SsK636B0KhhjrSVh5FS@mail.gmail.com> <4D058A97.firstname.lastname@example.org>
- Sender: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5
On 12/12/2010 08:53 PM, Mark Callow wrote:
> Please remind me why this clearing is necessary. If it is for
> "security" then surely this extra clearing is only necessary if the
> drawingBuffer is given to a different webgl context that original drew
> the contents.
> As I pointed out in a previous e-mail not all applications use
> glClear() because their other rendering will fill the entire buffer.
> In those cases following the above is overhead that cannot be
> optimized away. When I was at SGI, we used to go to enormous lengths
> to make sure the clear operation was fast because it has an enormous
> effect on the overall frame-rate. It feels really painful to be
> introducing extra clears.
In addition to the "Fast-Z-Clear" feature on Radeon 8000-series (which I
believe is kinda similar to the tricks that the SGI Onyx pulled), on
hardware as far back at the Radeon R100 (circa 2001!), things like the
heirarchical Z buffers ("Hyper-Z" in ATI-speak and "Lightspeed Memory
Architecture" in nVidia-speak) means that your program is often much
slower if it DOESN'T clear the screen at the start of each new frame.
nVidia have long been advising that the screen is cleared every frame -
even if it's immediately followed by a whole-screen draw (like a sky-box
However, I doubt that cellphones and Intel GPU's have such fancy logic.
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: