[Public WebGL] blitFramebuffer behaviour
Tue Nov 13 15:27:15 PST 2018
That's all I was asking for. I'm curious why you think there's a public mailing list if you feel the spec should only be discussed among browser devs.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, 13 November 2018 17:27, Jeff Gilbert <[email protected]> wrote:
> FWIW, Chrome is correct:
> WebGL 2 spec for blitFramebuffer:
> "If this function attempts to blit to a missing attachment of a
> complete framebuffer, nothing is blitted to that attachment and no
> error is generated per Drawing to a Missing Attachment.
> If this function attempts to read from a missing attachment of a
> complete framebuffer, and at least one draw buffer has an image to be
> blitted, an INVALID_OPERATION error is generated per Reading from a
> Missing Attachment. "
> On Tue, Nov 13, 2018 at 2:21 PM Jeff Gilbert [email protected] wrote:
> > If you think a browser's behavior is incorrect, file a bug with that browser.
> > On Tue, Nov 13, 2018 at 1:25 PM Tarek Sherif [email protected] wrote:
> > > This was not a bug report. My first response was to file the bug report on your bug tracker, as I mentioned. I was unaware of the concern with crash bugs, and I'll keep that in mind in the future.
> > > The purpose of sending to the mailing list was to discuss whether Chrome's behavior is correct.
> > > Tarek Sherif
> > > http://tareksherif.net/
> > > https://www.biodigital.com/
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Tuesday, 13 November 2018 15:13, Jeff Gilbert [email protected] wrote:
> > >
> > > > Hi.
> > > > Your first response to finding a browser bug should not be posting to
> > > > public lists about it. For behavior differences, reporting the bug
> > > > against one of the browsers is sufficient, since we constantly work to
> > > > guarantee cross-browser compatibility. In the bug filed against
> > > > browsers, browser devs will weigh in on what the proper behavior
> > > > should be, and will either fix it in their browser, or direct you to
> > > > file a bug against the browser they feel is out of spec. (Or maybe
> > > > browser devs will file that bug with the other browser)
> > > > Crash bugs in particular should not be publicized widely. Crash bugs
> > > > can be symptoms of security vulnerabilities, so a certain amount of
> > > > care should be taken.
> > > > I will now be taking a look at the bug reported to Firefox, and, as is
> > > > usual for this sort of issue, ensuring that behavior matches the spec,
> > > > both in Firefox, and across browsers.
> > > > Please do not use this list for bug reports unless the normal approach
> > > > to filing bugs falls short.
> > > > Thanks!
> > > > On Tue, Nov 13, 2018 at 8:22 AM Tarek Sherif [email protected] wrote:
> > > >
> > > > > Hi all,
> > > > > I just reported a bug to the Firefox devs about blitFramebuffer causing the browser tab to crash: https://bugzilla.mozilla.org/show_bug.cgi?id=1506840
> > > > > Essentially, if the read fbo has colour and depth attachments, while the draw fbo has only a color attachement, and the mask is COLOR_BUFFER_BIT | DEPTH_BUFFER_BIT, the tab will crash in Firefox. Minimal example: https://github.com/tsherif/webgl2bugs/blob/master/firefox/ff-blit-bug.html
> > > > > Chrome ignores the depth buffer in this case, but I'm not sure that behaviour is correct. The spec suggests it should be an INVALID_OPERATION error (section 4.3.3): "Calling BlitFramebuffer will result in an INVALID_OPERATION error if mask includes DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT, and the source and destination depth and stencil buffer formats do not match."
> > > > > I don't mind either way, as long as the behaviour is consistent across both browsers.
> > > > > Tarek Sherif
> > > > > http://tareksherif.net/
> > > > > https://www.biodigital.com/
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
More information about the public_webgl