premultipliedAlpha context creation attribute not being handled correctly |
||||||||||||
Issue descriptionIn longstanding WebKit bug https://bugs.webkit.org/show_bug.cgi?id=33386 it was reported that Chrome apparently isn't handling the premultipliedAlpha context creation attribute correctly. At least, Safari's and Firefox's notions agree; a pixel test and ideally, a reftest are needed once this is investigated and resolved so that this doesn't regress again.
,
Aug 16 2016
,
Aug 16 2016
It looks like there are still differences in behavior between Chrome, Safari and Firefox. Safari's and Firefox's output still look pretty similar. The problem probably needs to be fixed in the compositor, to make it better understand that the incoming texture from WebGL may already have the alpha channel premultiplied into the color channels. (This should already be the case, but I don't know where this code lives any more.) A more dramatic test case is needed which will more clearly demonstrate the differences in behavior.
,
Aug 17 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 17 2017
Still needs to be re-investigated. At minimum, the WebGL conformance test harness needs to support screenshots so that this behavior can be enforced among implementations.
,
Nov 10 2017
Is this fixed? The issue was reported on SO with a repo https://stackoverflow.com/questions/47216022/webgl-gl-fragcolor-alpha-behave-differently-in-chrome-with-firefox Shorter repo here https://jsfiddle.net/greggman/tcf0fnzo/ Chrome fails in v62 but it works in Canary v64 Also issue #645993 seems related
,
Nov 11 2017
Okay, so strange, The tests in my previous comment are broken in stable v62 Were working in canary 64.0.3263.0 are broken again in 64.0.3264.0 The left should be brown when correct. It's orange when not correct See screenshots
,
Nov 16 2017
On Mac I think we need to stop using IOSurfaces if premultipliedAlpha is set to false, since we don't have fine grained control over how the window server interprets the IOSurface. ccameron@ does this sound right? Certainly launching Chrome with --disable-features=WebGLImageChromium makes this render correctly. Was seeing a different incorrect rendering behavior on Windows, but that was with --disable-gpu , so using SwiftShader.
,
Nov 16 2017
Yes, IOSurfaces are always interpreted as premultiplied by the WindowServer. IMO we should have a path that does a copy to an IOSurface (with appropriate conversion), and we should consider using that for RGB emulation as well. (it needs to be remembered that by copying to an IOSurface we save an even larger copy being performed by the WindowServer, so it is always preferable to not using an IOSurface)
,
Nov 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/913195d22f782d61e86944b0ac0bfe45bf1df88e commit 913195d22f782d61e86944b0ac0bfe45bf1df88e Author: Kenneth Russell <kbr@chromium.org> Date: Sat Nov 18 01:17:46 2017 Avoid using IOSurfaces with premultipliedAlpha:false flag. Core Animation doesn't have the ability to honor this flag. Fall back to the regular OpenGL-based composition path in this case. Finally add a pixel test for this. BUG= 599285 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: I06ffe41b5080bab6d767472b0deb4b97142ead21 Reviewed-on: https://chromium-review.googlesource.com/776218 Commit-Queue: Kenneth Russell <kbr@chromium.org> Reviewed-by: Kai Ninomiya <kainino@chromium.org> Reviewed-by: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#517659} [add] https://crrev.com/913195d22f782d61e86944b0ac0bfe45bf1df88e/content/test/data/gpu/pixel_webgl_premultiplied_alpha_false.html [modify] https://crrev.com/913195d22f782d61e86944b0ac0bfe45bf1df88e/content/test/gpu/gpu_tests/pixel_test_pages.py [modify] https://crrev.com/913195d22f782d61e86944b0ac0bfe45bf1df88e/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp [modify] https://crrev.com/913195d22f782d61e86944b0ac0bfe45bf1df88e/third_party/WebKit/Source/platform/graphics/gpu/DrawingBufferTestHelpers.h
,
Nov 18 2017
,
Nov 18 2017
Finally fixed and tested. A follow-on bug's been filed about better optimizing this display path.
,
Nov 21 2017
,
Dec 5 2017
,
Jun 28 2018
Unfortunately I'm still have the different behaviour for the test https://jsfiddle.net/greggman/tcf0fnzo/. Canary (69.0.3475.0) and Firefox(61.0) shows brown left quad, but Chome(67.0.3396.87) draws it with dark green color. I think the problem with premultipliedAlpha=false still exists.
,
Jun 28 2018
#15: please file a new bug, include about:gpu from your machine, and email me the bug ID or post it here. Thanks.
,
Jul 3
I've just created a new bug here https://bugs.chromium.org/p/chromium/issues/detail?id=859822. Thank you.
,
Jul 3
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by kbr@chromium.org
, Aug 16 2016