Closed Bug 1143755 Opened 9 years ago Closed 9 years ago

WebGL conformance/extensions/webgl-draw-buffers.html test fails

Categories

(Core :: Graphics: CanvasWebGL, defect)

36 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: agostbiro, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [webgl-conformance] [gfx-noted])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36

Steps to reproduce:

Visit:
https://www.khronos.org/registry/webgl/sdk/tests/conformance/extensions/webgl-draw-buffers.html?webglVersion=1

with user agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0

Graphics:
Intel Iris 1536 MB


Actual results:

The following tests failed:

test clearing framebuffer that only has first half of attachments
attachment: 0 = COLOR_ATTACHMENT0, TEXTURE
attachment: 1 = 0x8ce1, TEXTURE
attachment: 2 = 0x8ce2, TEXTURE
attachment: 3 = 0x8ce3, TEXTURE
attachment: 4 = 0x8ce4, NO_ERROR
attachment: 5 = 0x8ce5, NO_ERROR
attachment: 6 = 0x8ce6, NO_ERROR
attachment: 7 = 0x8ce7, NO_ERROR
PASS attachment 0 should be 0,255,0,255
FAIL at (0, 0) expected: 0,255,0,255 was 0,0,0,0
FAIL at (0, 0) expected: 0,255,0,255 was 0,0,0,0
FAIL at (0, 0) expected: 0,255,0,255 was 0,0,0,0
PASS attachment 4 [details] [diff] [review] should be 0,0,0,0
PASS attachment 5 [details] should be 0,0,0,0
PASS attachment 6 [details] should be 0,0,0,0
PASS attachment 7 [details] should be 0,0,0,0

test drawing to framebuffer that only has first half of attachments
PASS attachment 0 should be 255,0,0,0
FAIL at (0, 0) expected: 0,255,0,0 was 0,0,0,0
FAIL at (0, 0) expected: 255,255,0,0 was 0,0,0,0
FAIL at (0, 0) expected: 0,0,255,0 was 0,0,0,0
PASS attachment 4 [details] [diff] [review] should be 0,0,0,0
PASS attachment 5 [details] should be 0,0,0,0
PASS attachment 6 [details] should be 0,0,0,0
PASS attachment 7 [details] should be 0,0,0,0

test clearing framebuffer that only has first and last attachments
attachment: 0 = COLOR_ATTACHMENT0, TEXTURE
attachment: 1 = 0x8ce1, NO_ERROR
attachment: 2 = 0x8ce2, NO_ERROR
attachment: 3 = 0x8ce3, NO_ERROR
attachment: 4 = 0x8ce4, NO_ERROR
attachment: 5 = 0x8ce5, NO_ERROR
attachment: 6 = 0x8ce6, NO_ERROR
attachment: 7 = 0x8ce7, TEXTURE
PASS attachment 0 should be 0,255,0,255
PASS attachment 1 [details] [diff] [review] should be 0,0,0,0
PASS attachment 2 [details] [diff] [review] should be 0,0,0,0
PASS attachment 3 [details] [diff] [review] should be 0,0,0,0
PASS attachment 4 [details] [diff] [review] should be 0,0,0,0
PASS attachment 5 [details] should be 0,0,0,0
PASS attachment 6 [details] should be 0,0,0,0
FAIL at (0, 0) expected: 0,255,0,255 was 0,0,0,0

test drawing to framebuffer that only has first and last attachments
PASS attachment 0 should be 255,0,0,0
PASS attachment 1 [details] [diff] [review] should be 0,0,0,0
PASS attachment 2 [details] [diff] [review] should be 0,0,0,0
PASS attachment 3 [details] [diff] [review] should be 0,0,0,0
PASS attachment 4 [details] [diff] [review] should be 0,0,0,0
PASS attachment 5 [details] should be 0,0,0,0
PASS attachment 6 [details] should be 0,0,0,0
FAIL at (0, 0) expected: 0,0,0,255 was 0,0,0,0


Expected results:

The tests should pass. The bug prevents the use of multi target framebuffers for rendering.
The bug persists in the latest nightly build as well.
I wasn't aware that Bugzilla automatically prepends user agent information to the report. To clarify, the user agent with which the bug occurred was:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0
Blocks: webgl-1.0.2
Component: Untriaged → Canvas: WebGL
Product: Firefox → Core
Summary: WEBGL_draw_buffers conformance test fails → WebGL conformance/extensions/webgl-draw-buffers.html test fails
Whiteboard: webgl-conformance
Whiteboard: webgl-conformance → [webgl-conformance] [gfx-noted]
I believe the same failure is being discussed at https://bugzilla.mozilla.org/show_bug.cgi?id=1136428, so we could close this and focus the discussion there?
This bug was fixed in Bug 1136428. Verified fixed with 43.0a1 (2015-09-02)
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.