Open Bug 1372181 Opened 7 years ago Updated 2 years ago

WebGL 2 conformance test conformance2/rendering/blitframebuffer-filter-outofbounds.html failures

Categories

(Core :: Graphics: CanvasWebGL, enhancement, P2)

55 Branch
enhancement

Tracking

()

Tracking Status
firefox57 --- wontfix

People

(Reporter: jujjyl, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [gfx-noted])

Running https://www.khronos.org/registry/webgl/sdk/tests/conformance2/rendering/blitframebuffer-filter-outofbounds.html?webglVersion=2&quiet=0 was tested to fail on - Apple Mac Mini (Late 2012) - Ubuntu 16.04 Xenial, Kernel 4.4.0-78-generic 64-bit - Firefox 55.0a1 (2017-05-22) (64-bit) - Intel HD Graphics 4000, Intel Mesa DRI Ivybridge Mobile, OpenGL 3.3 (Core Profile) Mesa 12.0.6 - Apple Mac Pro (Late 2013) - OS X El Capitan 10.11.6 - Firefox 55.0a1 (2017-05-22) (64-bit) - AMD FirePro D500 4.1 ATI-1.42.15 - Apple MacBook Pro 13" 2016 - macOS Sierra 10.12.3 - Firefox Nightly 55.0a1 (2017-05-21) (64-bit) - Intel Iris Graphics 550 1536 MB 4.1 INTEL-10.22.29 - Google Pixel XL - Android 7.1.2, Kernel 3.18.31-g416bf43 (marlin N2G47O), Fennec 55.0a1 (2017-05-19) - Qualcomm Adreno 530, OpenGL ES 3.2 V@145.0 (GIT@Idb2b4cb785) to error messages like failed: pixel at [1, 1] should be (0,0,0,0), but the actual color is (32,32,32,255) failed: pixel at [2, 1] should be (0,0,0,0), but the actual color is (32,32,32,255) failed: pixel at [3, 1] should be (0,0,0,0), but the actual color is (32,32,32,255) failed: pixel at [1, 2] should be (0,0,0,0), but the actual color is (32,32,32,255) failed: pixel at [1, 3] should be (0,0,0,0), but the actual color is (32,32,32,255) failed: pixel at [7, 7] should be (0,0,0,0), but the actual color is (32,32,32,255) failed: pixel at [2, 2] should be (0,0,0,0), but the actual color is (32,32,32,255) The test passed on - HP Notebook 14-am009no 14" - Windows 10 Home - Firefox 55.0a1 (2017-05-22) (64-bit) - Intel HD Graphics (Intel HD 400?) Direct3D 11, 20.19.15.4509 9-1-2016, OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f) - Haswell - Windows 10 Home 64-bit - Firefox 55.0a1 (2017-05-22) (64-bit) - 2x ASUS NVidia GeForce GTX 1080 Ti Direct3D 11, v22.21.13.8189 (4-19-2017), OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f) - Intel NUC6i7KYB Skull Canyon - Windows 10 Pro 10.0.14393 64-bit, Firefox 55.0a1 (2017-05-22) (64-bit) - Intel Iris Pro Graphics 580, 21.20.16.4534 (10-7-2016), OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f) - Supermicro X10DAX 1.02 - Linux Mint 18 Sarah, Kernel 4.4.0-36-generic 64-bit, Firefox 55.0a1 (2017-05-22) (64-bit) - ASUS GeForce GTX 1060 OpenGL 3.2.0, NVIDIA 370.28 - Microsoft Surface Pro 2 - Windows 10 Pro, Firefox 55.0a1 (2017-05-22) (64-bit) - Intel HD Graphics 4400 Direct3D11 v20.19.15.4331 (11-18-2015), OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f) - Samsung Galaxy S7 Edge SM-G935F - Android 7.0, Kernel 3.18.14-11104523 (NRD90M), Fennec 55.0a1 (2017-05-19), ARM Mali-T880, OpenGL ES 3.2 v1.r12p1-03dev0.228ab63cced004f840e7dd47b762a1d0 - Huawei P10 Plus - Android 7.0, Kernel 4.1.18-gfd75bbb (VKY-L29), Fennec 55.0a1 (2017-05-19) - ARM Mali-G71, OpenGL ES 3.2 v1.r2p0-02dev0.f7269486f3e0e3b308edf85872e361f4
Has STR: --- → yes
Priority: -- → P3
Whiteboard: [gfx-noted]

Spec:

For any source pixel lying outside the read framebuffer, the corresponding destination pixel remains untouched.

I don't think this is actually implementable...

I'm tempted to try making OOB reads here an INVALID_OP and see if we get any compat bugs.

Type: defect → enhancement
Depends on: 1559556
Priority: P3 → P2
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.