[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: Cedric Vivier <firstname.lastname@example.org>
- Date: Mon, 13 Dec 2010 11:24:28 +0800
- Cc: "Gregg Tavares (wrk)" <email@example.com>, public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=XZ99CU8mzrQUXVews5VWYm8BZaGYsWJ9EEDvMNURy0w=; b=xmI1SiE2lWwxEOanD9AzVfj/dPPV0MluMn0W1H2g0MOw3AL+IQrhfwdnVex1WbbqOl U5TqXkp+gK4eGwyb9VWcVSWX6k7XqXVIvJ9X+N9RBL7sBRjzRdR7DNAE2rn2mC5S8ePq cGj553+fjrfmOq7HNpIy6qw71bwJaWj4Zu0lg=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=M+OM7haQqNdzxC27AGfqe3a9zMBgSMj2BdFT6N3mhZvrUG2IBRRbGur7qycz/0Zudo kqfu/JOUOFNHaWZHQyXQOjMWusdwUtIhGN5bCxyLaSAKTQcVSsWVQco1H79rK3l+8Bkb Pvleh7agFrsdY2rILeAEtHnRxh5K32a6OSsGM=
- 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
On Mon, Dec 13, 2010 at 10:53, Mark Callow <firstname.lastname@example.org> wrote:
> 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.
> I also don't quite understand this part
Same here, also aren't we going towards exposing a
presentFramebuffer() or equivalent?
The paragraph defining how/when the drawing buffer is presented is
confusing at best imho.
When does the compositing happens exactly? Does it always happen right
Granted a "present()" would probably have to be asynchronous
internally, it provides a very clear definition of frame presentation
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: