[Public WebGL] Updating the Spec W.R.T. preserveDrawingBuffer = false

Bill Baxter [email protected]
Tue Jun 11 11:31:34 PDT 2013

On Mon, Jun 10, 2013 at 7:22 PM, Jeff Gilbert <[email protected]> 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.
> 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

> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20130611/931ad9a8/attachment.html>

More information about the public_webgl mailing list