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)
Tracking
()
NEW
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
Updated•7 years ago
|
Has STR: --- → yes
Priority: -- → P3
Whiteboard: [gfx-noted]
Updated•7 years ago
|
status-firefox57:
--- → wontfix
Updated•5 years ago
|
Comment 1•5 years ago
|
||
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•