[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, Jun 10, 2013 at 7:22 PM, Jeff Gilbert <jgilbert@mozilla.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.

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.

--bb