1261565 - WebGL uses incorrect texture coordinates on Mac OSX 10.11.4

Status: RESOLVED INVALID

(Core :: Graphics: CanvasWebGL, defect)

Description

[neil.kronlage]

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

Steps to reproduce:

Simplified repro is at: http://www.colorizephoto.com/firefoxbug/repro.html

This sets up a few WebGL shader programs and buffers.  The final draw fills the canvas with an image.


Actual results:

The image does not fill the canvas. It only occupies the top right and is clamped in the rest of the canvas.


Expected results:

The image should have filled the entire image.

Safari, Chrome, Edge, IE11 all render this with the image filling the canvas.

Comment 1

[neil.kronlage]

Note, this repros for me on a Macbook Air 2010 running OS X 10.11.4.

Comment 2

[neil.kronlage]

Attachment: Incorrect Stretching

Comment 3

[Loic]

I can't reproduce it with 47/48 on Win 7.

Is it reproducible with a fresh profile?
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 4

[neil.kronlage]

Thanks for trying this out. I tried an Asus laptop running Windows 10 and cannot reproduce the problem there. So it may be Mac specific. I don't have any other Macs to see if it affects other versions or just mine (Late 2010 MacBook Air 11") 

I also tried removing all my profiles and that did not affect the behavior.

Here are the graphic card details from System Information:

NVIDIA GeForce 320M:

  Chipset Model:	NVIDIA GeForce 320M
  Type:	GPU
  Bus:	PCI
  VRAM (Total):	256 MB
  Vendor:	NVIDIA (0x10de)
  Device ID:	0x08a2
  Revision ID:	0x00a2
  ROM Revision:	3571
  Displays:
Color LCD:
  Display Type:	LCD
  Resolution:	1366 x 768
  Pixel Depth:	32-Bit Color (ARGB8888)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Built-In:	Yes

Comment 5

[Jerry Shih[:jerry] (UTC+8) (inactive)]

I can reproduce with my mac device.

Comment 6

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Attachment: expect result

Comment 7

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Hi Jeff,

Please check the simplified webgl code: https://pastebin.mozilla.org/8866690

The attachment 8737483 [details] results from the second time we setting the vertex attrib.

My problem is that why we still can get the result as attachment 8738930 [details].
Since the last binded buffer only have position information, the texCoord data is undefined.


After rebind and reset with the correct buffer and attrib, I can see the expect result as attachment 8738930 [details].
Please check: http://people.mozilla.org/~hshih/bug1261565/repro.html


Safari, Chrome, Edge, IE11 and firefox at linux, windows, all render this with the image filling the canvas.
I'm not sure the attachment 8738930 [details] is the correct one.

Comment 8

[Kelsey Gilbert [:jgilbert]]

I suspect this is a bug in the app's (likely implicit) assumptions about location orderings.

I believe we will find that on affected machines:
`program2.attribs.vertexPosition.location != program.attribs.vertexPosition.location`
But rather:
`program2.attribs.vertexPosition.location == program.attribs.texCoordIn.location`

Comment 9

[Kelsey Gilbert [:jgilbert]]

Confirmed this on my Macmini with AMD GPU.

This is a bug in the testcase, not the browser.

Comment 10

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Hi Jeff,
Is the vertexAttribPointer setting a global status or the status within the buffer?
If it comes with a buffer, we only need to setup the vertexAttribPointer setting once not for every buffer binding.
My question is that why we bind a invalid buffer but still can get the texture coord?
Please check https://pastebin.mozilla.org/8866690 line 30

Comment 11

[Kelsey Gilbert [:jgilbert]]

(In reply to Jerry Shih[:jerry] (UTC+8) from comment #10)
> Hi Jeff,
> Is the vertexAttribPointer setting a global status or the status within the
> buffer?
> If it comes with a buffer, we only need to setup the vertexAttribPointer
> setting once not for every buffer binding.
> My question is that why we bind a invalid buffer but still can get the
> texture coord?
> Please check https://pastebin.mozilla.org/8866690 line 30

It's state attached to specified vertex attrib. vertexAttribPointer stores the current ARRAY_BUFFER, so you can rebind the buffer and use a different one for another vertexAttribPointer.