[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Re: double-buffering and back buffer preservation
- To: Vladimir Vukicevic <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Re: double-buffering and back buffer preservation
- From: Vangelis Kokkevis <email@example.com>
- Date: Thu, 18 Nov 2010 16:42:42 -0800
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290127365; bh=dAwOxviiwscq1ZKbj/Xfb07QTPU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=oceeOoAKwAhlWCFPhPB/zGVE5HdhOjzWUKh3yh/PGgvyhzg/ABA9TsUqoetkxtsul 6GfGe46OdXG8rkEQ3Ir3w==
- 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=8hG+KhaUDwaAqgiXXIgdIHUz/JXGI9YaseAQpoNZb/s=; b=GnoFUffffj3mnO5vOhmXLdfCfGjTGMoPTw6S3RAc9B5112ThYU542z+7ukJE+ih4fs Wd1m0HRmTvu1O3BCFbNg==
- 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=bC+Qq5LSAwOZ3ogr/OoSoSeAR6Y3FSTBipCgdNEiXViwIdbwT/+VkpumzbVHiZNQyg 0yQoRWDIGGpOGcXpWPsg==
- In-reply-to: <1172884978.380241.1290109112064.JavaMail.email@example.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <2033847348.354199.1289858189572.JavaMail.firstname.lastname@example.org> <1172884978.380241.1290109112064.JavaMail.email@example.com>
- Sender: firstname.lastname@example.org
On Thu, Nov 18, 2010 at 11:38 AM, Vladimir Vukicevic <email@example.com>
There's a pile of pros and cons for almost any set of choices here :-) Here's what we've come up with:
- Anything that will read from the color buffer (readPixels, drawImage, etc.) is fair game before a present happens. It will return the correct results for current rendering.
- Present will continue to happen implicitly as it does today.
- A context attribute will be added, provisionally called preserveDrawbuffers, which will default to false.
- When a present occurs:
- if preserveDrawbuffers is FALSE: the color/stencil/depth buffers are set to the default values.
- if preserveDrawbuffers is TRUE: the color/stencil/depth are untouched.
- If a canvas/webgl context is used in a way that its contents are not directly displayed to the screen, then no present ever occurs. For example, creating an offscreen canvas which is then used as a source for drawImage only without being attached to the displayed DOM.
Applications can continue to use readPixels, drawImage, etc. normally, as long as they coordinate with the webgl drawing and do it in the same JS execution period as their WebGL drawing. If they need to arbitrarily do drawImage/etc., then they can set the preserve flag and be able to do so. We considered an explicit present, but there are many complexities with that approach that implicit was simplest, without obviously making any use cases impossible.
The above semantics should make it possible to implement WebGL in the most performant way possible on various mobile hardware, and can allow a WebGL implementation to take advantage of functionality such as EXT_discard_framebuffer.
This also implies that when preserveDrawBuffers is FALSE it won't be possible to print WebGL content or create a thumbnail of the page (such as those used in the new tab page).
A few notes:
1) When JS execution finishes and control returns to the browser, there's no requirement that a present /will/ happen before the next user JS execution. This means that even with preserveBackbuffer being false, it's possible to have the contents of the buffer be what they were from the previous rendering. However, it was decided that this is preferable to introducing the complexities of an explicit present, and is the reason why the buffer is cleared after a present -- an application that accidentally takes advantage of this should notice problems more readily than without the clear. If someone does end up relying on the implicit clear by accident, it's an easier fix than if they were relying on previous contents being available. Also, implementations can warn if drawing happens after a present with no intervening clear() call.
2) The clear in the case of not preserving the back buffer is understood to be a lazy clear; it shouldn't introduce any overhead for well-written applications.
You are currently subscribed to firstname.lastname@example.org
To unsubscribe, send an email to email@example.com
the following command in the body of your email: