[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Ambiguity and Non-deterministicness in the WebGL Spec
- To: Steve Baker <email@example.com>
- Subject: Re: [Public WebGL] Ambiguity and Non-deterministicness in the WebGL Spec
- From: "Gregg Tavares (wrk)" <firstname.lastname@example.org>
- Date: Sun, 12 Dec 2010 21:23:02 -0800
- Cc: public webgl <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292217783; bh=iVM5zzk97WjFrRK2iWAw0SpRYk0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Wr8LTf7zRku4RKVxSE8wWaZZ38PwULxTCpA1xUYAy+VjF5l/hlHM5UKFmifDGrUDM YobAsBavE1wkH6cwTDiWg==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=S8/IIpogCpBS32nl9CQ3CvEL/c4ldctovpkpqFhPmDo=; b=izFrYt7FlR/Jrh+oAm22eahMXgaWUq8JVotHSlx3OTI+hWBx/l5C7RNobW7M56LmZg js1F5RptUkeM9w4RJnvQ==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=m+SAsblZdV155S1Wiontg+7xfFs+NeuOM/9mf4xIn59WclgxP7E7JW/oEpanGgk1p6 joRvHqEk30vZ3Kv2Lavg==
- In-reply-to: <4D05AECA.firstname.lastname@example.org>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <AANLkTimA1yWqLNpQ_qEQ67tJ9SsK636B0KhhjrSVh5FS@mail.gmail.com> <4D05AECA.email@example.com>
- Sender: firstname.lastname@example.org
On Sun, Dec 12, 2010 at 9:27 PM, Steve Baker <email@example.com>
On 12/12/2010 04:20 PM, Gregg Tavares (wrk) wrote:But what about honoring things like the ColorMask, DepthMask and Scissor
> The spec has changed to effectively require a clear each time the
> WebGL draw buffer is composited
> WebGL presents its drawing buffer to the HTML page compositor
> immediately before a compositing operation, but only if the
> drawing buffer has been modified since the last compositing
> operation. Before the drawing buffer is presented for compositing
> the implementation shall ensure that all rendering operations have
> been flushed to the drawing buffer. By default, after compositing
> the contents of the drawing buffer shall be cleared to their
> default values. This includes the color buffer as well as the
> depth and stencil buffers if they are defined
> drawing buffer will be composited and therefore when the buffer will
> be cleared. For example, if a tab is hidden there may be no
> clear the buffer for it each time it returns control the browser it
> may be wrong.
> passes control back to the browser rather than the arbitrary only when
> Also, the spec says they will be cleared to the default values. I
> thought there was some discussion about clearing them to whatever the
> current clear settings are. Was there some reason that was dropped?
settings? Those things limit the ability of the clear screen function
to reset every pixel to a known state.
Clearing to the current ClearDepth, ClearColor and ClearStencil seem separate to me from ColorMask, DepthMask and Scissor in that 99% of all programs will most likely not use ColorMask, DepthMask or Scissor but will use ClearColor, ClearDepth and possibly ClearStencil.
If you honor their settings, then the application can easily get around
whatever thing you're trying to make happen by effectively shutting off
write access to the frame buffer - so I suppose you'd have to save,
force & restore those kinds of things each time.
All of the implementations already handle saving and restoring the scissor state, color mask and depth mask to handle resizing the backbuffer and clearing its contents. So having it clear to the current color, mask, stencil rather than the default seems pretty straight forward.