[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Updating the Spec W.R.T. preserveDrawingBuffer = false
Apologies for the delayed reply to this thread.
On Tue, Jun 11, 2013 at 7:30 AM, Mark Callow <firstname.lastname@example.org> wrote:
> The purpose of DiscardFramebufferEXT is to tell a tiling GPU that is does
> not need to copy the data corresponding to the current tile from the
> framebuffer of the previous frame into the tile memory prior to rendering.
> It has no effect whatsoever on the content of a framebuffer. Copy-to-tile
> only needs to be done when pDB==true. When pDB==false, the browser can
> always call DFExt before calling the WebGL app's draw function.
Thanks for the clarification.
On Tue, Jun 11, 2013 at 8:05 AM, Gregg Tavares <email@example.com> wrote:
> As I said, it makes no sense to me that I can print the canvas, I can move
> the canvas in the DOM, I can apply CSS animations and effects to the canvas
> but I can't get it's content. The content exists. It seems like I should be
> able to get it one way or another.
> Under the DrawingBuffers proposal most of this goes away. You can pass a
> DrawingBuffer to texImage2D or call DrawingBuffer.toDataURL, and what you
> get is 100% clear. readPixels and copyTexImage2D are also 100% clear in both
> cases. They are always the DrawingBuffer that is current on the context.
> It's only the canvas case that needs clarification and that's because it has
> this buffer copy/swap stuff going on behind the scenes.
I agree that it should be technically feasible to get access to the
last composited version of the canvas. The clarification about
DiscardFrameBufferEXT from Mark above indicates to me that it's
supportable even on mobile platforms.
On Tue, Jun 11, 2013 at 8:31 PM, Bill Baxter <firstname.lastname@example.org> wrote:
> On Mon, Jun 10, 2013 at 7:22 PM, Jeff Gilbert <email@example.com> wrote:
>> I don't think it's so unreasonable the way it is, but I can see the
>> benefit in allowing for screenshotting.
>> However, it would pull things out of line with what readPixels will give
>> you back.
> May just be me, but not lining up with readPixels seems much less bad than
> undefined behavior.
>> This is also potentially non-trivial on Firefox OS.
Jeff, could you explain why in more detail? Doesn't the browser still
have access to the last framebuffer that was produced for the
>> Why do devs not just use pDB=true if they need this functionality? If they
>> really do need the bit of extra perf (which should be quite uncommon), why
>> not add an option to do a screenshotting frame render?
> pDB=false does give a noticeable performance boost on fill-limited systems,
> so Maps currently uses it on machines that appear to be fill-limited.
> It may indeed be a smallish subset of apps that need that boost, and if
> you're one of those apps and you're down to turning off
> preserveDrawingBuffer to get an extra bit of perf (as we are), it's probably
> the case that you're working hard on all parts of your app. So requiring
> some extra effort to make screenshotting work may not be too much burden.
> Our workaround will be to do a screenshotting frame render, then add that
> screenshot image to the DOM over top the canvas before invoking the Feedback
> API, then remove it afterward. It is certainly doable, and we will probably
> have to do it anyway since changing the spec would take a while. But still,
> it would be easier for future apps not to have to do that.
>> I can see this making life easier for some, but I believe it may prove to
>> be a headache to implement in some cases, where most apps can use pDB, and
>> the rest can do their own screenshotting?
> I think it's certainly a cost-benefit situation. How much headache it is to
> implement in WebGL for how many, vs how many apps will benefit by how much.
> I don't have any data on how many apps will ever run into this, but the
> number of WebGL implementations is certainly small. I would say if ~100
> apps can avoid special code to get WebGL screenshots, vs 1 or 2 WebGL
> implementations struggling to comply, then it's probably a win.
> But I have no idea how many WebGL apps there will be that run into this.
> Nor do I have any idea how much work it would actually be for WebGL
> implementers. Just guessing it's around 100x as painful as the js-side
> workaround in the worst case.
The cost of implementing this behavioral change in WebGL seems fairly
small, at least on desktop and some mobile platforms. The motivation
comes from a real-world use case and if this change were made, I think
it would make the behavior much better and more consistent. I hope
that there aren't any showstoppers on iOS and Firefox OS and would
like to explicitly solicit detailed feedback from those vendors about
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: