Issue metadata
Sign in to add a comment
|
WebGL Textures created from Canvas2D are truncated to 256x256 on Windows 7 and 8
Reported by
gil...@koffeeware.com,
Apr 6 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: 1. open https://jsfiddle.net/2pha/e6rbt3r4/ 2. see if the cube is correctly textured (full face visible or half the face visible) What is the expected behavior? Cube faces textured with a full character face ; the texture is created from a 512x512 Canvas2D. What went wrong? Since Chrome 57, on Windows 7 and 8, any WebGL Texture created from a Canvas2D is truncated to 256x256, you will thus not see the full face of the character in the jsFiddle above. This probably does not affect all users of Windows 7 and 8 but we have had a lot of reports of this problem, all from users on Windows 7 on 8. The problem does not seem to be there for Textures created from an Image. Users all confirm the problem appeared only with Chrome 57. Worked fine in previous versions, works fine in all other browsers. This problem has been widely reported from users of our webgame http://starblast.io ; after investigating the problem, we found this existing jsFiddle which better characterizes the problem. Did this work before? Yes Chrome 56 Does this work in other browsers? Yes Chrome version: 57.0.2987.133 (64-bit) Channel: stable OS Version: Windows 7 and 8 Flash Version:
,
Apr 6 2017
,
Apr 6 2017
Works on my windows bot (win7 NVidia Quadro K2200) It might be GPU/driver specific. Can you share about:gpu content on some affected machines?
,
Apr 6 2017
Can't reproduce on: Chrome/57.0.2987.133 ANGLE (AMD Radeon R7 200 Series Direct3D11 vs_5_0 ps_5_0) OpenGL ES 3.0 (ANGLE 2.1.0.c1a5d16e964a) Driver version 21.19.519.2 Reporter: please copy+paste and send the contents of chrome://gpu on the affected machine. Otherwise we won't have any way to reproduce.
,
Apr 7 2017
We asked affected users to send us their chrome://gpu ; attached is the first we received.
,
Apr 7 2017
Thank you for providing more feedback. Adding requester "kainino@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 7 2017
We also got confirmation from one affected user that our temporary workaround fixes the problem; the workaround consists in converting the canvas to an Image using canvas.toDataURL and invoking THREE.Texture constructor on the Image instead of the original canvas (using THREE.js)
,
Apr 7 2017
I noticed both of these reports are on D3D9 (GLES 2) on Win 7. * Win 7, ANGLE (AMD Radeon HD 6410D Direct3D9Ex vs_3_0 ps_3_0) * Win 7, ANGLE (Intel(R) HD Graphics 530 Direct3D9Ex vs_3_0 ps_3_0)
,
Apr 7 2017
Confirmed that --disable-d3d11 reproduces the problem. I wonder if this can act as a smaller test case for Issue 709162 .
,
Apr 7 2017
Note that --disable-accelerated-2d-canvas works around this bug.
,
Apr 7 2017
Separately from the bug on D3D9, here's a possible hint on why D3D9 is being used at all (from the pdf): [3488:3492:0407/184840.248:ERROR:angle_platform_impl.cc(33)] : ANGLE Display::initialize error 0: No available renderers. [3488:3492:0407/184840.248:ERROR:gl_surface_egl.cc(676)] : eglInitialize D3D11 failed with error EGL_NOT_INITIALIZED, trying next display type
,
Apr 7 2017
Will look at this when I have time. Feel free to snag.
,
Apr 7 2017
Re #12, they might not have the platform update installed. The platform update is required for cross-process HWND sharing.
,
Apr 7 2017
Narrowed this to an ANGLE roll: https://chromium.googlesource.com/angle/angle.git/+log/41f9f67..133a2ec I think these are the only possible suspect changes. I'll check each: f1cf5e6 Prevent stack overflow in macro expansion 28cb036 Check for misconfiguration of shader built-ins 55482a1 Don't require npot extensions in ES3 contexts. 78b0c91 Fix infinite recursion in macro expansion 44f2648 Framebuffer: Fix getDepthStencilAttachment check. However the others could be more suspicious than their subject lines. Anyway, will follow-up with the culprit CL.
,
Apr 7 2017
Problem CL: Add support for CHROMIUM_copy_texture with D3D9. https://chromium-review.googlesource.com/339813 Author: Geoff Lang Investigating now.
,
Apr 7 2017
Issue 709162 has been merged into this issue.
,
Apr 7 2017
This partial revert fixes the rendering again, but there may be an easy fix. https://chromium-review.googlesource.com/c/471848 Will continue to investigate Monday if it's still available by then.
,
Apr 7 2017
Thanks Jamie for narrowing down the regressing CL! Not sure whether we should aim to do this partial revert or push forward with finding a fix. No huge rush. Wonder if this is also the cause of Issue 709162 ?
,
Apr 11 2017
The following revision refers to this bug: https://chromium.googlesource.com/angle/angle/+/46258e1fcab289c22017068e2c93f77ae75c9ec1 commit 46258e1fcab289c22017068e2c93f77ae75c9ec1 Author: Geoff Lang <geofflang@chromium.org> Date: Tue Apr 11 18:12:42 2017 Blit9: Pass the dest rect to setViewportAndShaderConstants. Using the sourceRect for calculating the viewport and texture coordinates was not enough when the source and destination rectangles were different sizes (generating mipmaps). BUG= 709232 Change-Id: I2704ddf6e3da0939ad77d278ab495e53a2d9bc7d Reviewed-on: https://chromium-review.googlesource.com/473266 Commit-Queue: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org> [modify] https://crrev.com/46258e1fcab289c22017068e2c93f77ae75c9ec1/src/libANGLE/renderer/d3d/d3d9/Blit9.cpp [modify] https://crrev.com/46258e1fcab289c22017068e2c93f77ae75c9ec1/src/tests/gl_tests/MipmapTest.cpp [modify] https://crrev.com/46258e1fcab289c22017068e2c93f77ae75c9ec1/src/libANGLE/renderer/d3d/d3d9/Blit9.h
,
Apr 11 2017
,
Apr 12 2017
Following up from https://bugs.chromium.org/p/chromium/issues/detail?id=709162 Would it still be useful if I collect and chrome://gpu info from our users?
,
Apr 12 2017
@james: no, the issue is now fixed in ANGLE and will be rolled into Chrome today. You should be able to have the users verify that the issue is fixed in tomorrow's Canary.
,
Apr 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/41a618265465c164db0083511143b0bab5cdc697 commit 41a618265465c164db0083511143b0bab5cdc697 Author: geofflang <geofflang@chromium.org> Date: Wed Apr 12 21:59:25 2017 Roll ANGLE 20e005b..67f5ce4 https://chromium.googlesource.com/angle/angle.git/+log/20e005b..67f5ce4 BUG=602688, 709980 , 709232 TBR=cwallez@chromium.org TEST=bots CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2816793002 Cr-Commit-Position: refs/heads/master@{#464164} [modify] https://crrev.com/41a618265465c164db0083511143b0bab5cdc697/DEPS
,
Apr 13 2017
,
Apr 18 2017
Nice fix!
,
Apr 18 2017
Agreed, thanks Geoff for the fix! Question: was this covered by any WebGL conformance tests?
,
Apr 21 2017
@kbr: I'm not sure, I'm guessing not. It was hard to write an ANGLE test for this even, it required attempting to generate mipmaps into a texture that was already mip complete and had already been used for rendering.
,
May 24 2017
Issue 725957 has been merged into this issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by kbr@chromium.org
, Apr 6 2017