[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] blitFramebuffer behaviour
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@example.com> 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 <firstname.lastname@example.org> 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@example.com> 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 firstname.lastname@example.org 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@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: