[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] double-buffering and back buffer preservation
- To: Chris Marrin <email@example.com>
- Subject: Re: [Public WebGL] double-buffering and back buffer preservation
- From: "Gregg Tavares (wrk)" <firstname.lastname@example.org>
- Date: Thu, 18 Nov 2010 10:17:43 -0800
- Cc: Vladimir Vukicevic <email@example.com>, public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290104267; bh=M29LupurPxzp1WENzoxhWjMvB6Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=XyT8oSwF7bXFqN6s7PVWkQtNa2i77qJkfX4MWpEH+cx2w1vHz9vBN+kKg0uZZS47J 667JttjEaxwaoH8emhG/g==
- 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=8Ai76PAeOcZ6DC75uMkhufS4fkZdSss9VxZiRjtz//U=; b=aFkMlFUX0+aFP/Vhy1KQfo+wfRUFRAle+PzuQD0SMQiRGKi9iG+LV8dti/MS/gkw91 g+a7nrFo5UVgvEJPnmdg==
- 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=SjTEzlgLXXYcazbayHgIaaA6YK2W0UIMtQSIkqcS+l1ayrYx4qnC2ok+ba3wsKE4/z 7+Pv9B8gjNeH3f3DX2pQ==
- In-reply-to: <B983903E-643E-4C76-B3CD-A813379164CA@apple.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <68153838.357344.1289892251441.JavaMail.email@example.com> <B983903E-643E-4C76-B3CD-A813379164CA@apple.com>
- Sender: firstname.lastname@example.org
You actually end up needing 3 buffers to have an explicit present on the desktop I think.
The reason is multisampling / anti-aliasing. WebGL has a antialias context creation attribute. In that case 2 buffers are currently created. A multisample draw buffer (MDB) and a resolved display buffer (RDB). Anytime toDataURL, drawImage, readPixels or texImage2D is called where the contents of the draw buffer are needed we have to blit the MDB into the RDB before you can read the pixels out. Since present is implicit currently that's okay because the RDB is going to be used for rendering anyway when JS finally exits and will be over written. If we changed to an explicit present then we'd need a 3rd work buffer anytime any of those 4 functions was called since we have to resolve the MDB and we can't use the RDB except for present.
Maybe that's ok. That 3rd buffer could be dynamically created and freed since none of those calls are expected to be that fast. I just thought I'd mention the added complication needed to support explicit present. I still like the idea of explicit present.
On the opposite side, A problem with the implicit present + implicit clear is offscreen rendering. If I make a canvas with the sole purpose of doing GPU computation or just making images that I'm going to use in a canvas2d drawImage call and my WebGL canvas isn't even connected to the DOM why should it be cleared when JS exits? With explicit present that problem would go away. (or without implicit clear as it is now that problem doesn't exist)