Chrome and reading two textures in WebGl fragment shader

[Ronen]

Hi,

In a fragment shader I read from two textures to create a result pixel.

In rare clients the result pixel is wrong as if one of the textures was garbled or missing. When a client has this symptom - it happens all the time on this client.

1. It is related to Chrome - doesn't happen using IE on the same client

2. When I use a single texture it works OK. I prefer to use two textures though to represent the image.

3. We have many lapotps of the same kind - all work OK except for a single one that shows the symptom

4. I compared the results of Chrome:\\gpu and chrome:\\flags between a good and a bad client (same hardware) - results were exactly the same

5. One client started to show this symptom after connecting to a different monitor (it was working fine before) 

Any idea why this could happen? Could a monitor affect Chrome WebGl in this way? how I can detect it beforehand to fallback to using a single texture? 

The only thing I could think of is to render a demo picture using two textures vs using a single texture and compare, but maybe there is a simpler solution to detect / fix the issue.

Thanks,

Raanan

[Kenneth Russell]

Please file a bug with a test case, and feel free to email me the bug ID directly. Please include about:gpu from a system where the problem is happening. There's no reason why sampling two textures in a fragment shader would be arbitrarily broken, so something else must be going wrong. A long time ago we saw corruption of multisampled renderbuffers on macOS when an external monitor was plugged in, but issues like that haven't come up recently.

-Ken

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/011361bf-0984-4326-958f-fe71b8ec2532%40chromium.org.

[Raanan]

Hi Ken,

I correct myself - the problem is not related to two textures, but to the fact that one of the textures is an HTMLImageElement created from a PNG blob (the PNG is RGB24 e.g. without Alpha channel).

I was able to reproduce the error (again only on this rare machine where it happens) just by using a single HTMLImageElement texture created from PNG of RGB24(not RGBA) - and render to webgl.

In this case I also see that the ImageData pixels of this HTMLImageElement (after drawing to an in-memory canvas) are different from the original uncompressed pixel data.

So it seems as if the decompression of the PNG by Chrome was somehow incorrect (again only on this rare environment, and on another machine related to a monitor being changed (weird)).

Does this shed more light on the issue? any ideas I can try? I think I'll try RGBA PNG, or maybe change the alignment of the RGB buffer from 4 to 8 bytes.

Thanks,

Raanan

[Kenneth Russell]

Raanan,

It sounds like you need to use WebGL's pixelStorei API to set the UNPACK_PREMULTIPLY_ALPHA_WEBGL parameter to false and UNPACK_COLORSPACE_CONVERSION_WEBGL parameter to NONE. The latter will avoid any transformations of the PNG data into the colorspace of the display, which Chrome is moving away from doing regardless. But we can't fully diagnose the issue without a self-contained test case.

-Ken

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/3d46942b-323e-4ea9-b187-42f97fbb09c5%40chromium.org.

[Raanan]

Hi Ken, I was lucky, this issue was solved in Chrome 61... The single machine that showed the error suddenly worked well after a reboot, so I checked, and it updated to 61. I uninstalled 61 and installed 60 again - and the error came back, I did the moves between 60 and 61 a few more times, and it seems that whatever issue that was in Chrome with PNG decompression, it was solved in 61.

I still this have this issue in CEF, as there is no CefGlue yet for 61, but for this I wrote a small test that compares a 2x2 synthetic image, between the decompressed PNG and the raw pixels, to detect whether the issue manifests itself or not. This test tells me whether it is safe to use PNG or not in this environment. Indeed on the machine with the issue, the test fails on Chrome 60, but succeeds on Chrome 61.

Using pixelStore API didn't fix the issue with Chrome 60 (nor did it change the correct behavior with Chrome 61), but I use it since it is good advice, thank you very much!

Thanks,

Raanan