New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 889027 link

Starred by 3 users
Status: Duplicate
Merged: issue 878545
Owner:
█ kbr@chromium.org
OOO until 2019-01-24
Closed: Sep 26
Cc:
kainino@chromium.org
chelamcherla@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Resizing a large image and drawing it to a WebGL canvas gives a black image

Reported by kocsis1d...@gmail.com, Sep 25 
Steps to reproduce the problem:
1. Load a large image
2. Copy it to a different sized temporaray canvas using 2d context
3. Upload an image to gpu using the temporary canvas
4. Render with that texture

What is the expected behavior?
The resized texture is drawn on the screen.

What went wrong?
The texture became black. The GLSL texture2D function always returns a black color.

Did this work before? Yes 

Chrome version: 69.0.3497.100  Channel: stable
OS Version: 5.1
Flash Version: 

We tried to run the attached file on different Android versions with the new Chrome version, but it always gives a black image. On desktop it works well. Some images also work, e.g. an image with width of >10000px worked.
index.html
4.0 KB View Download

Comment 1 by kocsis1d...@gmail.com, Sep 25 

If I call tempContext.getImageData() before using the WebGL context, then it renders the correct image.

Comment 2 by chelamcherla@chromium.org, Sep 26

Labels: Needs-triage-Mobile

Comment 3 by chelamcherla@chromium.org, Sep 26

Cc: chelamcherla@chromium.org
Labels: -Pri-2 hasbisect-per-revision ReleaseBlock-Stable M-69 Target-69 FoundIn-69 Pri-1
Owner: kbr@chromium.org
Status: Assigned (was: Unconfirmed)
Tested the issue in Android and able to reproduce the issue. 

Steps Followed:
1. Opened attached html file in chrome -- observed black image 

Chrome versions tested:
69.0.3497.100

OS:
Android 9.0.0

Android Devices:
Pixel 2

Issue is seen in latest stable but not seen in latest dev #71.0.3555.2, latest beta #70.0.3538.27 and latest canary #71.0.3562.0. Hence providing reverse bisect info.

Bisect range:
==============
Last Bad Build - 70.0.3538.18
First Good Build - 70.0.3538.19

Manual CL: https://chromium.googlesource.com/chromium/src/+log/70.0.3538.18..70.0.3538.19?pretty=fuller&n=10000

Suspecting https://chromium.googlesource.com/chromium/src/+/44e4cbed9b8a798d3c7aeff627c79057383a6361 from changelog.

@kbr: Could you please check the issue and help in re-assigning if this is not related to your change.Please let us know if this issue requires merge to M-69. Adding RB-Stable for M-69, please remove if this is not applicable.

Thanks!

Comment 4 by hablich@chromium.org, Sep 26

Cc: -chelamcherla@chromium.org sindhu.chelamcherla@chromium.org kainino@chromium.org
As kbr@ is OOO, Kai, could you please take a look?

Comment 5 by hablich@chromium.org, Sep 26

Cc: -sindhu.chelamcherla@chromium.org chelamcherla@chromium.org

Comment 6 by kainino@chromium.org, Sep 26

Components: -Blink Blink>WebGL
Mergedinto: 878545
Status: Duplicate (was: Assigned)
I'm actually OOO at the same conferences, but anyway...

As indicated by #3, this has been fixed already and merged back to 70 already. 
Per  issue 878545 #c28 , we won't merge to 69.
►

Sign in to add a comment